Saturday, June 30, 2012

Output Buffering and Default Settings

I recently needed to set up a new development system with Apache and PHP. The last time I configured these two programs was when PHP was at 5.2.x and the ZIP file included a php.ini-development. The most recent version of PHP is 5.4.4 and does not include a php.ini-development.

The PHP application being developed on this system offers a setting for compressing the output for client browsers that support compression. When I turned on this setting, I received this error:

ob_start(): output handler 'ob_gzhandler' conflicts with 'zlib output compression'

Nothing had changed in the PHP application. The only thing that changed was the PHP version. If I were a little less experienced, I may have thought that I found a bug in the latest version of PHP. Instead, I figured that either something had changed in the API and my implementation had been incorrect from the start, or I had something configured wrong.

I compared the php.ini from the old 5.2.x with the php.ini from 5.4.4 and found a difference in the output_buffering setting.

In 5.2.x, the php.ini-development has output_buffering set to Off. In 5.4.4, output_buffering is set to 4096. I set output_buffering to Off and I am no longer receiving the error.

Thursday, May 31, 2012

.NET Exceptions and Performance

I had an application that was performing very poorly under a fairly heavy load out in the real world. It got me thinking about doing more performance testing, both within a profiler and under simulated loads. The profiler pointed out some key flaws in the code that were quickly dispatched, but the problems still remained.

I enlisted some help to simulate more realistic loads and really stressed out the application and I started getting errors that I shouldn’t have been getting. So I thought. The code that was generating the errors wasn’t thread-safe. In an effort to reduce the number of error emails I was receiving, I surrounded the offending code with SyncLocks and the errors stopped.

A side benefit was that the performance issues went away. It was then that I discovered that exceptions can cause some performance hits due to the extra objects required.

So, if you can help it, minimize exceptions (I could in this case) and watch for thread-safety in code that may be run with multiple threads.

Thursday, March 15, 2012

Unshelving with Merge Conflicts

My team at work uses mercurial for source control. One of the concepts in the mercurial is a “shelf” where you can place partially completed work while you take care of synchronizing your local repository with another repository. You don’t always have to place items on the shelf, but some operations in mercurial require a clean local repository.

A coworker recently placed some items on his shelf and then synchronized his repository. When he went to “unshelve” his changes, there was a conflict. The (redacted) error text read “Unshelve Abort patching file <filename.ext> Hunk #<number> FAILED at <number> <number> out of <number> hunks FAILED – saving rejects to file <filename.ext>.rej”. He had been working on one of the files that had also been updated during the synchronize. Technically, the original shelving operation was unnecessary as mercurial is intelligent enough to merge conflicting files. The shelving was done, however, and he still needed his changes that were on the shelf.

The ultimate solution was the revert the repository back to the point of the shelving, then proceed with the synchronization without shelving.

There may be another way to tell the shelf that the conflicts have been resolved and it can continue (like with hg transplant --continue). If you know of a way to do this, feel free to let me know.