As a follow-up to his previous article about the (minimal) overhead from logging, Kevin Schroeder has this new post focusing on the common belief that writing to the file system is the slowest method.

I had a conversation the other day by a person I respect (I respect any PHP developer who knows how to use strace) about the cost of file IO. My assertion has been, and has been for a long time, that file IO is not the boogeyman that it is claimed to be. So I decided to test a cross between those two posts.

His test was to write one million log records to two different sources - the normal physical file system, a RAM drive - one run with a file handle that's left open and the other with a new handle each time. He shows how he made the RAM drive and the PHP he used for the test (running in a VM). He graphs out the results with some interesting results...but you'll have to read the post for that.

In this new postJoseph Scott takes a look at hashing in PHP, specifically around md5 hashes, and a better alternative (that's also more secure.

The majority of the Coding Horror: Speed Hashing post talks about speed based on MD5. [...] If you are still using MD5 to hash passwords (or worse, aren't hashing passwords at all) then please stop and go use bcrypt. For those using PHP phpass is a great option.

He talks about the crypt method, how its encryption method and "cost" value effects the speed and how difficult it would be to generate all possible hashes for a password (hint: crypt with a cost of 13 is worlds better than md5).

Derick Rethans has posted just a few of the reasons why the "shut-up operator" (the @ symbol) should be avoided at all costs in your PHP applications.

The @-operator is often used to silence errors in noisy PHP functions'"functions that generate warnings that can not be easily prevented. [...] In those cases, there is no way how to check up-front whether the function call will not issue a warning when being called.

There are side effects to using the operator, however, including hiding legitimate errors and making debugging that much more difficult. To back up his point, he includes four other reasons to avoid the operator's use (besides the debugging issues):

It's slow (part 1)

It's slow (part 2)

It's slow (part 3: It generates crappier code)

Apfelstrudels were harmed (related to the strudel_token in the C code for the operator)

Tobias Schlitt has, for a personal project, put together a comparison of caching with two different web servers he's building applications with - Apache and Lighttpd.

For a little private project, which makes extensive use of caching, I recently checked, where I could get gather some more performance from.

He had been pointed towards Lighttpd by Kore (who recommended it based on his experience with it). So, Tobias tested the application on both of the two servers with somewhat predictable results (see image). Apache was slower in most cases and quite a bit slower when it came to working with larger files.

Everyone that knows of the social news site Digg.com knows the problems that being linked on it can cause. Smaller servers get overloaded and pages can either be very slow loading or completely offline within minutes of being "digged". There's a few out there that have come up with different solutions, but several of them involve mirroring the content somewhere else. In this proposal, however, they combine the power of Lightttpd and PHP to handle the loads.

We host a wide variety of sites, covering everything from converting your garage into a living space to video game addictions. Because we are such a small operation, being hit by a link from a big site such as Digg would be both a blessing and a curse.

In order to place our ads on each page, we use PHP's auto_append_file feature to run our advertisement code. By using PHP's other neato function, auto_prepend_file, I can create a small piece of PHP code to detect when the site is being hit by Digg. In this situation, I have chosen to use Lighttpd to handle the increased loads, because of its proven high performance with large numbers of concurrent connections.

In his example code, he shows how you can detect when a user is coming from a digg.com page and take them to a cached version of the page they've requested (with the .cache extension).

We all have software that we love, and we all have software that we hate. Sometimes, there's even a few times in there that there's software that we love to hate. Jim Plush has this kind of love-hate relationship with Zend Studio as expressed in this letter.

Dear Zend Studio, thank you for giving me a remarkable debugger to use which saves me countless hours during the day. Unfortunately, I hate that you make me wait 2 seconds before rending text to the screen. I hate your unusable slowness.

I hate that I bought a beautiful mac with the amazing OSX GUI but you make me disable "OS LOOK AND FEEL" just so I can type in your lovely editor. It turns my lovely GUI into a 1980's screen shot of the first linux GUI ever made. Ohhh but your debugger, you minx. It's got me hooked and I can't give it up. I've tried the others and I keep returning to your sleek lines in the first 5 minutes when you actually work properly.

Love/Hate always,
Jim

We've all been there and know this pain. It's good to see he's taking it in stride and is expressing it with such fine sarcasm too...