I think there is something wrong with Matt’s argument in that he overlooks the fact that we are talking about open source here. The developers of said applications are probably all among the people that have servers available. So if the decide to move on, its only a question of the hosters flipping the switch to increase the number of machines they deploy their PHP5 images on.

Optaros, the company I am working for, released an open source catalog which lists close to 300 so called "enterprise ready" OSS applications. I guess most of you reading my blog are not exactly in the target group as to me it mostly seems to be directed about people that lack deep networking into the various OSS communities. That being said I still think that it might be worth a look, even if its just to blog about how we totally got the rating on a specific piece of software totally wrong.

Georg, Andrey and Ulf have been hard at work designing, implementing and testing a replacement for libmysql only for us PHP users. The idea is that mysqlnd can leverage all the internal PHP infrastructure for communication and memory management. It can also be much more PHP aware, removing old cruft we do not need while adding extra goodies just for us!

One interesting solution to scalability and HA is to implement a circular master-master replication setup directly on the frontend servers. Obviously there is a reasonable limit as to how many servers you can have in such a ring, since the lag with which changes propagate will increase linearly as you add more servers to the ring. However according to an article by Giuseppe a 10 server ring is reasonable. Especially if you make your sessions sticky on a per frontend server basis, you actually have an elegant solution against the old issue of replication lag, where a user does not see changes he has made in subsequent requests, since his changes were written to a remote master server which have not propagated to the slave he is reading in the subsequent request. Latency should also improve as you do not have to open up a remote connection in the user request.

I just wanted to point everybody at a recent blog post by Konstantin. In the post he discusses a solution for dealing with cache invalidation issues of very large caches under heavy load. He points out that cache invalidation can severely bog down the system. The general solution he proposes is to simply deactivate the query cache entirely during invalidation. I think this is an important caveat to be aware of and actually he is asking for feedback if this "solution" is acceptable. I think its awesome that MySQL engineers are giving us the opportunity to provide feedback on such changes. Maybe there should be a dedicated "pipeline" where such requests could be found?