Posted
1 day
ago
by
Evert Pot
SolarPHP's framework now comes with SQL adapter for MySQL replicated setups since the 1.0.0alpha2 release. The adapter automatically picks master or slave databases depending on the type of query. If its a SELECT, it will go to a slave, if its a
... [More]
UPDATE, DELETE, etc. it will automatically go to the master.
Let me just put it out there, I think that's a really bad idea. While this will work for certain situations, it is advertised as "The Solar_Sql_Adapter_MysqlReplicated adapter handles all the connections and switching-around for you, and you don't need change a single line of application code.".
Quite frankly, I started out with a similar approach. It worked fine for our staging environment, which didn't experience a lot of load, when it went to the live machine things went bad.
Suddenly I realized there were more than couple places in the application that had to do SELECT based on information that was just INSERT'ed. After the INSERT was done, the SELECT was performed on the slave, while the data hadn't arrived yet from the master. This caused some pretty freaky errors. Hoping to fix the problem, I decided to always execute any query on the master after an data-altering statement was done. Turned out that the master got quite a bit more load than the slaves after that change.
Things got worse when there was a replication lag of say, a second. Users would modify some data by submitting a form, and when they ended up on a resulting page the data was gone!
Some of the things we looked at was using a whitelist or blacklist for queries that are always ok/not ok to go to the slave, but considering we then ended up with decoupling a logical block of code, we went for the pragmatic approach. Always pick the master or slave depending on what is required for a specific piece of functionality. Yes, it might require a bit more thinking as you're working on your database code, but the behaviour is predictable and reliable. [Less]
Posted
25 days
ago
by
Evert Pot
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
... [More]
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! [Less]
Posted
29 days
ago
by
Evert Pot
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
... [More]
query, it will be very easy to spot the origin of some of your queries.
/* recent blogposts */ SELECT id, title, time FROM blogposts ORDER BY time DESC limit 10
The comment will show up as the first thing in SHOW [FULL] PROCESSLIST, MySQL administrator and your log/slow-log files. [Less]
Posted
30 days
ago
by
Evert Pot
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
... [More]
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.
Are you using lighttpd or an other alternative 'light' webserver using PHP under high load environments? Have you experienced similar issues?
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?
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.
And most importantly, whats your moms favourite color? [Less]
Posted
about 1 month
ago
by
Evert Pot
The Zend Framework has a pretty good OpenID library. I was looking for a library written for PHP5 (strict), and this seemed like a good choice..
The Zend library requires a storage backend to record and cache some of the information, and it
... [More]
was very easy to implement a custom one for our database layer. There's a bunch of good examples are available on the documentation page (although they were slightly outdated with the current api and did contain sql injection problems..).
The only drawback I saw was that there was a hard dependency on the Zend frameworks' Session system. I didn't want to write an adapter for our own platform, so ended up overriding the 'verify' and '_checkId' methods to simply use PHP's built-in $_SESSION array.
The odd thing was that the changes I made to the OpenId_Consumer class only set stuff in the session, but I didn't find anything that actually retrieved those values.
On a completely off-topic note, I just got my copy of High Performance MySQL, and I'm pretty excited to read it :) [Less]
