Gena01.com Forum
December 14, 2017, 05:21:29 am *
Welcome, Guest. Please login or register.

Login with username, password and session length
 
   Home   Help Search Tags Login Register  
Pages: [1]
  Print  
Author Topic: Performance tips, APC vs Eaccelerator  (Read 37312 times)
0 Members and 1 Guest are viewing this topic.
Gena01
Administrator
Sr. Member
*****
Posts: 423



WWW
« on: February 11, 2008, 11:25:21 pm »

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
Logged
Rene Leonhardt
Guest
« Reply #1 on: February 14, 2008, 08:12:18 am »

Easy MySQL performance profiling with the built-in Slow Query Log

MySQL queries can easily be profiled with the built-in query logger, with MySQL 5.1.21+ (or a patched 5.0) even with microseconds granularity.

Just run the application as normal and filter the Slow Query Log afterwards with an easy though customizable script:
php mysql_filter_slow_log.php --exclude-user=root --no-duplicates linux-slow.log > mysql-slow-queries.log

Activate the Slow Query Log in my.ini:
log-slow-queries
# Log only those queries that run 1 second or more (microsecond resolution is supported since 5.1.21)
long_query_time=1
# Additionally log all queries which do not use indexes
log-queries-not-using-indexes
# MySQL 5.1.6 through 5.1.20 had a default value of log-output=TABLE, so you should force
log-output=FILE

http://code.google.com/p/mysql-log-filter/
Logged
Gena01
Administrator
Sr. Member
*****
Posts: 423



WWW
« Reply #2 on: February 14, 2008, 10:22:31 pm »

As of 5.0.37 MySQL has profiling (http://dev.mysql.com/doc/refman/5.0/en/show-profiles.html) support. And yes slow query log can help you find bad queries and maybe add some missing indexes or tune tables. You can also diagnose and tune things from a dba perspective. Here are some great presentations on the topic: http://mysql.meetup.com/7/files/

So yes, there are many things that could be done and problems could get analyzed and fixed at many levels (if possible). Things get pretty bad if those queries need to get rewritten and at times it's quite hard to locate the script that actually ran a particular query.

One important point that I do want to make is that I love to trace executions per page if possible, especially during development. Also users tend to report specific pages or URLs as being slow.  Database is usually the reason why things are slow, but not always. I've seen plenty of examples where the time spent was doing some other stuff like doing execute from PHP or file i/o. I can also see that quite clearly from an xdebug trace. Just follow the timeline and see the jumps in numbers. Also it provides you with the final timing inside apache and the server-side execution of a script vs the time it took to receive the last byte from the server.

I guess I could post an article explaining how to get those numbers and what they would mean. And what you can do to address some of those timings to make them better.

Gena01
« Last Edit: February 14, 2008, 10:31:27 pm by Gena01 » Logged
Gena01
Administrator
Sr. Member
*****
Posts: 423



WWW
« Reply #3 on: February 17, 2008, 04:48:18 pm »

In relation to MySQL and performance I am posting a couple of links to various tools:
1. http://mysqltuner.com
2. MyTop (http://jeremy.zawodny.com/mysql/mytop/) - MySQL Top script
3. MySQL Report (http://hackmysql.com/mysqlreport) - this one I used before and it has very nice reporting functionality that can optionally provide even more details.

Gena01
Logged
Tags:
Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines | Sitemap Valid XHTML 1.0! Valid CSS!