Performance tips, APC vs Eaccelerator

There have been a number of articles and talks on performance lately. Overall this is quite common and I am sure that this topic will be quite popular for a long time. There are a lot of website out there that manipulate data in some shape or form. As long as traffic is low this is usually not a problem, but once traffic picks up then the website becomes slow or unresponsive. This problem is quite common and in some cases has nothing to do with PHP. Some websites use other technologies like Java and face the exact same problems. There are different variables involved here and the most common one is database. So I thought i would post a couple of articles related to performance and tuning.

Before I add my own five cents here are a couple of items that were posted recently on the web:
- Performance Tuning Overview by Mike Willbanks (http://blog.digitalstruct.com/2008/01/31/performance-tuning-overview/)
- More about performance tuning by Stuart Therbert (http://blog.stuartherbert.com/php/2008/01/31/more-about-performance-tuning/) - somehow this website is slow to load?
- Improve Performance: Check your Loops (http://blog.adaniels.nl/articles/improve-performace-check-your-loops/) - has PHP specific optimization tricks
- ZendCon Sessions: Episode #7 - "High Performance PHP & MySQL Scaling Techniques" (http://devzone.zend.com/article/3005-The-ZendCon-Sessions-Episode-7-High-Performance-PHP-MySQL-Scaling-Techniques) - this is a great session that was recorded during ZendCond (http://www.zendon.com) PHP Conference. The link contains both slides and audio of the session.

Actually the last link is one of the reasons behind this post: Why APC?

I mean yes I know a lot of people use it:
- FaceBook (http://www.facebook.com) uses APC and has done a couple of sessions of explaining how they use APC during PHP Tek (http://tek.phparch.com/) conference.
- Digg.com (http://www.digg.com) seems to use it, since Eli works there.
- and yes I know APC will be included with PHP 6 - Upcoming PHP6 additions and changes (http://davidwalsh.name/upcoming-php6-additions-changes/)
So before people start to flame me I've been following up and doing my research. Somehow when I use APC (http://pecl.php.net/package/APC) i just don't see such big performance improvements as people claim. Don't get me wrong APC has some nice things and by implementing some neat tricks you can get more out of it. I just feel that the last time I tried the stable version it didn't have everything that was mentioned during the FaceBook presentation. Also on a couple of occasions combining APC with some PHP packages just breaks. One example is phpMyAdmin which apparently does something ugly with it's config file so it doesn't play nice with APC (was this fixed already?).Yes I am a big fan of eaccelerator (http://eaccelerator.net/). I have used it on a number of projects and websites and it has consistently performed great for me. It also seems to perform better than APC (and yes this is probably biased until I prove this). It also supports session handling (something I really like) where the session information is stored inside eaccelerator (in shared memory and not in some /tmp location where /tmp is being cleaned out regularly). In terms of other features eaccelerator also has very nice API interface you can use with your PHP code. (most caching extensions have quite similar API for storing and retrieving values).

So here are some of my recommendations:
#1: get some sort of PHP accelerator + caching engine. If you don't know why then see the link from the ZendCond session above.
#2: Use Sessions (http://us3.php.net/manual/en/ref.session.php) when it makes sense. I've seen so many cases where using Sessions would have simplified things greatly. Also make sure that your sessions are using an optimal storage mechanism. If you are using MemCached (http://www.danga.com/memcached/) and need your session information shared by mutiple servers then PECL Memcache (http://pecl.php.net/package/memcache) extension could be great help since it has a session handler as well. There are a lot of PECL extensions that can be plugged-in and will handle your session handling by changing one php option: session.save_handler. Please, please, please don't store your sessions in a database. (SMF has an option to store sessions in the database? - not sure if it's the default, but I disabled this setting recently) Also please don't cache things back into the database. I saw people cache results of a query back into another table in the database instead of fixing the original query. Which bring me to the point #3.
#3: Don't try to throw everything at your poor database. People love taking the easy way out. It's also quite simple to code and do. They also tend to think of a database as a black box and as far as things work they can put more things there. If and when database problems happen they wake up in shock and blame the database. Also claiming that you are using or know an abstraction library and that makes you a good programmer is not an excuse. Yes the API is clean and consistent across the databases, but you want your code to run fast and scale. You can't get the most optimal queries by working and thinking that by using the most basic SQL you can get away with it. At times using database specific things tends to make things work much better. Also Pear DB is horrible with Oracle and Stored Procedures (ever try to write complex Queries?).
#4: Xdebug (http://xdebug.org/) - this is a MUST for a development environment. Why do people do print statements to find out why their code is running slow? What if it has nothing to do with the database? PHP has tools, learn them, use them. Xdebug also has a debugger. I will post a separate thread on how to do remote debugging with a full screen Windows Native syntax colored debugger that allows you to trace and step through the code and analyze values of your variables. And it's Open Source! Which reminds me, if you haven't seen this then go and read Introducing Xdebug (http://devzone.zend.com/article/2803-Introducing-xdebug) at DevZone. What I love to do is to setup Xdebug to generate trace files and then read through them looking for performance problems without changing a single line of my code.
#5: Look and analyze the queries that you are running against the database. Personally I hate it when some library builds the SQL for me out of some pieces. I don't know what the resulting SQL looks like and I am not sure if I like the overhead and hiding of details. But that's just me. I also love to profile and know approximate costs of most of the queries that I write. If some page somehow starts to run slow I run an xdebug trace, find the problem spot and pull up the query and run an explain plan to see why a query is running slow. (Maybe somebody changed something or changed an index). Also while I am on the queries topic make sure you are not doing stupid things: like getting one column from a table and then on the next line getting another column from the same table and from the same row. Save those queries! Don't do filtering or sorting on the client side, use your database to do that with WHERE and ORDER BY. Did you know that if you have your indexes setup right ORDER BY comes for free. Oh, btw ALWAYS put ORDER BY if you want the results sorted, don't assume.

And before I finish off I found the following article cute and interesting: 40 signs you really are a lousy PHP programmer (http://reinholdweber.com/?p=19).

This actually turned out a lotter bigger than anticipated. So bookmark it and come back and catch up on all those links and articles. There's a lot of good information out there.

P.S. I have finally been able to set this up so Guests can start posting again. Let me know what you think. Post some interesting links to articles if they are related to performance and PHP.

Gena01

	Author	Topic: Performance tips, APC vs Eaccelerator (Read 86588 times)
0 Members and 1 Guest are viewing this topic.