Hacker News Reader

Comment by qeorge | Hacker News Reader

I'm expecting the book to go much further than this. Your list is a fine starting point, but its fairly basic and lacks specifics.

I want to know about the weird things that happen when you push your PHP stack to really ridiculous limits. I think that's what this book will offer. If it ends up being stuff like "use APC! minimize trips to the DB!" I would be very surprised and disappointed.

View on HN

I agree- good starting point, but the book will be much more in depth. It's going to include a fair amount of high-level design, identifying how and where to scale, weird issues you run into (fun fact: we don't use APC @ Twitpic), solutions to PHP anti-scaling quirks (you can't set sub-1s mySQL timeouts, for instance, although I think this is due to libmysql, not PHP), lots of case studies, scaling design patterns, and way more cool stuff.

What was your experience with APC? You still use some opcode cache, right?

If you use a persistent PHP stack like mongrel2 + photon an opcode cache is just a waste of a php module.

http://www.photon-project.com/

Wouldn't you lose one of the advantages of PHP which is that every request is stateless and that when it fails it doesn't fail hard killing the application?

Not any more nowadays. I am the original author of Photon and today PHP is extremely robust and you can catch all the exceptions/errors (outside the ones which are making your code invalid, but hey, do your homework). The current PHP 5.3 is also wonderful at not leaking memory. So you get the speed of bare PHP with a framework (because nothing is reloaded, the framework can really load once, reuse many times).

On a small system, a standard HTTP request through Mongrel2, to the framework and back is about 2ms (including 1ms of network latency between the hosts, data from my production monitoring). This is the "hello world" latency. It makes using PHP very fun and very fast. Also, a single PHP process running in the background uses about 12MB, it means that with 12MBx3 + 10MB Mongrel2, you can serve 1000's of users with nearly no load on your system (if you push the load only when needed at the DB level). Tracing a PHP process, you can run it without system calls at all (only gettimeoftheday for logging).

But, this is cutting edge, so, you need to be open minded and ready to dig in the code (less than 25k SLOC anyway I think).

Current PHP is 5.4. Did you perform any test or benchmark with the new version? Do you gain anything from it? By the way, your project looks very interesting!

Very limited tests, one PECL extension for my projects was updated to support 5.4 only recently. The biggest win will most likely be for the POST payload (multipart) parsing because 5.4 is faster on array/strings. The good point is that with PHP farm, you can run both 5.3 and 5.4 in parallel to compare :)

If it's pushing PHP to ridiculous limits you seek then you want Facebook's HipHop compiler. But web stack design is really an art form, hard to summarize in an HN comment.

Reply on news.ycombinator.com