performance

What, nginx is not fast enough for you? Well, if you have a very high load that's quite possible (although unprobable :P ). I've learned and tested quite a few things about nginx optimization by reading this article:

http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/

You have put your puppet master behind Passenger and that lasted for some time. But now that you're beginning to have quite a good number of hosts that checkin to your master regularly, performance has started to become an issue. What can be done about it?

There are multiple answers. The first and simplest would be to put more space between your puppet runs. Say you're currently running puppet every 30mins on each client, you could change that period to 45mins or 1h.

It's also possible to distribute runs via a central scheduler that would ensure to run every node before going back to square one. One such solutions is the "puppetcommander.rb" script that R.I. Pienaar wrote to use mcollective as the run scheduler.

Another method (that you can use in conjunction with the above) is to cache the responses that come from the puppet master.

I just listened to this presentation by Avery Pennarun about how Python can be very fast if you use the appropriate techniques, and how those techniques are actually graceful ones.

I've been working for some weeks now to optimize a client's MySQL databases. I consider myself an apprentice MySQL DBA (e.g. there's much room for me to improve :P ), and I've found the process to be difficult. Although there is a whole lot of information about what to do and how -- some blog posts out there are absolutely invaluable -- the settings are not always straightforward to understand, since they often have many impacts and to correctly modify them, you need to understand what they do and how they change things under the hood for MySQL.

After bumping table_cache and tmp_table_size / max_heap_table_size up, I was left with one weirdness: the table cache is marked as being nearly empty (good) but there were a lot of query cache prunes (bad). This situation actually makes the cache add latency for most cases (in other words, it slows down tremendously your database).