If you're new here, you may want to subscribe to my RSS feed. Thanks for visiting!
Chatspring exists now. All of the features that will be in 1.0 are there!!
Hizaa!
Of course that means its time to pay a lot of technical debt. All of those little, fun things, like escaping user input, ie compatibility, and of course….optimization.
Here’s a little sampling of what I’ve learned.
1) Message queues are a gift from God: Last weekend I wrote a little queue server using python and the twisted framework. That immediately gave me a 500% performance increase for insert-heavy work.
2) Memcache w/ php is slightly slower than the mysql cache. I’ve been testing this all morning. Even when I give mysql 1000’s of inserts and retrieve data at the same time, it’s still faster. I think this arises from the fact that I have to create an additional TCP connection to use memcache, where as I already have a mysql connection open. (So memcache may be faster in a perfect world, but not in my app)
3) A lot of performance tweaks are more about consistancy than about pure performance. They may be slower in certain cases, than non-optimized code, but they make your app work consistently under changing conditions.
Plus a bonus tip:
If you’re using php, don’t forget to use one of the code caches like eAccelerator. That’s an immediate 100% performance boost with no need to change your code.
4 comments ↓
Regarding #2, it really depends on your implementation. The MySQL query cache is relatively small, and if your application uses lots of user-specific queries (which are hard to cache), then the MySQL cache effectively becomes useless.
In addition, at a certain point memcache also becomes convenient for partial page caching - bypassing both MySQL queries AND html code generation.
Another piece of advice I’d pass along is to take the extra time to build SQL queries that are both indexed properly and only retrieve the absolute minimum amount of information needed.
Totally agree with the code caching suggestion. I use Zend Platform instead of eAccelerator, but the effect is the same.
Good luck with your new app!
That’s a good tip, thanks!
I don’t think I was really using memcache the way that it was supposed to be used, so that could account for those results.
Yeah - “thing I learned # 5″ should have been “I don’t know nearly enough about sql tuning” Still looking for a good book on that.
In general, your database won’t need much tuning until it starts growing in size (premature optimization is evil). I built one app that’s been running since 1999, and I probably haven’t spent more than 10 minutes optimizing the SQL since it only has a few hundred MB of data and still runs speedily.
That being said, as your application grows, here is the type of thing you should look out for…
SELECT * FROM users WHERE username=’foo’;
SELECT * FROM access_levels WHERE user_id=’$row[user_id]’;
versus this optimized query…
SELECT user_id, username, password, access FROM users JOIN access_levels USING(user_id);
The “EXPLAIN” MySQL command is your friend. Regarding a book, “High Performance MySQL” is a good place to start.
It’s not done yet, but feel free to check out my scalability guide at http://www.squidoo.com/scaling-a-web-app.
Cool! Thanks. I’ll go check that out right now..
Leave a Comment