Het Bijstere Spoor

Just posted a new SabreAMF version to googlecode, containing mostly bugfixes and a few enhancements. (download). Updating is highly recommended, this release was supposed to get out a bit earlier, but I wanted to test it in a live environment for a bit first.

Changes:

• We're now throwing an SabreAMF_InvalidAMFException instead of a generic Exception in the event on a corrupt/incorrect AMF request. (contribution by: Asbjørn Sloth Tønnesen.)
• Fixed a bug in the standard Recordset object (identified by 'datafirm').
• Fixed string reference problem occuring with multiple AMF3 bodies, identified by sylvinus and fixed with help from the PyAMF team. Thanks guys!
• Fixed a bug in AMF3 integer encoding. For some small ranges you would end up with the wrong integers in PHP. The integer decoder is also a lot faster now (Fixed by Kevin Martin).
• SabreAMF_Server now allows alternative inputs than php://input (patch by Asbjørn).

Thanks guys!

MySQL allows comments to be added with the standard /* */ syntax. If your application is getting more complex, it can become more difficult to figure out where certain queries originate from.

By simply adding a comment in front of your query, it will be very easy to spot the origin of some of your queries.

The comment will show up as the first thing in SHOW [FULL] PROCESSLIST, MySQL administrator and your log/slow-log files.

In trying to get more out of our webservers using a Lighttpd and PHP-FastCGI setup, I've come across some major issues that make it difficult to use. I hope this post will warn people of some of the bugs they might encounter and workaround that might need to be implemented until some of these are fixed.

First off, the parent PHP-CGI process spawns n number of children, depending on your PHP_FCGI_CHILDREN. However, if your webserver (lighttpd) is stopped, or restarted, the parent process does not kill its children and they all get orphaned.

The only way to get around this easily is by making sure that as soon as you need to stop or restart your webserver, you do a 'killall php-cgi' while the server is still down. There's a PHP bugreport open, which seems to indicate the issue also happens in Apache. Vote for it!

The second, more severe issue is that when you hit maximum capacity for your PHP backend, lighty will start serving HTTP 500 errors for all PHP requests, and does not seem to stop doing this until the webserver is restarted altogether. Although not completely sure, these bugs seem to be the relevant ones:

• PHP bugs #41229 and #43610.
• Lighttpd bugs #784, and #897.

So yea, based on this information it turns out that there's a clear need for some smart process killing/webserver restarting scripts if you'd like to switch to lighttpd in a high load environment. I got pretty scared trying this after finding these bugs. Makes me think no one really tried it out under heavy loads, which leads me to some questions.. Hopefully some readers of this feed have some experience here.

1. Are you using lighttpd or an other alternative 'light' webserver using PHP under high load environments? Have you experienced similar issues?
2. What are good ways around PHP's FCGI buggy behaviour (the buggy part is that PHP's parent process should return FCGI_OVERLOADED instead of timing out.) Should FCGI be avoided altogether at this point?
3. What is a good way to come up with settings for 'max-procs' and 'PHP_FCGI_CHILDREN'. Reading other people's comment on this on the web people are all across the board, ranging from 1 for max-procs and 200 for PHP_FCGI_CHILDREN, to the exact opposite. Supposedly APC is isolated to 1 group of processes, so getting at least bigger groups of processes is important.
4. And most importantly, whats your moms favourite color?