11

What performance tips can be offered to someone running a LAMP server?

In the instance that something is Distribution specific, I'm targeting Debian.

pQd
  • 29,561
  • 5
  • 64
  • 106
Unkwntech
  • 1,762
  • 3
  • 19
  • 24

3 Answers3

26

It really depends on your workload.

  • for the L part

    • get a lot of memory,
    • if you can go over 4GB, go 64bit.
    • for partitions where your content, logs and MySQL data are use mount options: noatime, nodiratime.
    • use separate physical drives / raid sets, ideally keep SQL data, logs, content you serve - each on separate spindle.

  • for the A part of your stack - well maybe you want to replace it completely with nginx or lighthttpd, or maybe just leave Apache for dynamic content and have separate server (like those two or mathopd) for static content. Take a look here for more options. If you are going to run both Apache and another server at the same box, a 2nd IP address will be handy. To decrease latency for the end-user use http/1.1 with keep-alive. Consider using a CDN for static content.

  • for the M part of your lamp - take a look at mysqlperformanceblog. from the top of my head:

    • log slow queries,
    • give enough memory,
    • consider using innodb.
    • if you have a lot of text to search across - use sphinx and have a batch job that rebuilds the index.
    • consider killing queries that run longer than XYZ seconds. It's better to upset 1% of users than to bring the whole site down at the peak time. But that really depends if you process cash transactions or show nice pictures.
    • use memcached if you can, to cache result of more 'expensive' SQL queries. Keep in mind to invalidate the cache when you change content of SQL. On the other hand I have quite few sites where all data fits in memory comfortably and for that MySQL is blazing fast and there is no need of additional cache.

  • for P

    • set execution timeout for scripts.
    • consider using some PHP accelerator / opcode cache. I was quite satisfied with xcache, but I don't use it now.
    • if you have CPU intensive processing - cache results and store them in SQL or memcached

Not really a performance tip, but do take offsite backups. Really.

Glorfindel
  • 1,213
  • 3
  • 15
  • 22
pQd
  • 29,561
  • 5
  • 64
  • 106
  • 1
    if i may add this, i recently blogged about secure backups with push and pull strategies via amazon s3. not viable for bank data, but everything you will trust amzon with should be fine. http://www.logaholic.de/2009/05/21/secure-backups-with-push-and-pull-strategies-via-amazon-s3/ – Karsten May 24 '09 at 10:28
  • i have actually noticed that blog post before you commented ;-]. nice one anyway. you can always encrypt your backup to make it more secure. – pQd May 24 '09 at 10:47
3

I really suggest separating MySQL and Apache/PHP on two different machines.

For example, I had one machine (C2D E6600) that always spiked to 2.0 and above load average. I put the MySQL on a second machine (P4C 3Ghz) and after that both load averages did not go above 0.2-0.3. So I went from a really slow site to a fast site with two servers having a lot of performance margin.

Antoine Benkemoun
  • 7,314
  • 3
  • 41
  • 60
  • good point. i can only speculate that your bottleneck could have been IO subsystem / drive responsiveness. maybe then separating data on two different drives / having fine disk controller could do the trick as well. anyway more memory, and more cpus is always good, but then you get more possible points of failure as well. – pQd May 24 '09 at 13:28
  • Well, I'm not so sure it was disk I/Os because most (let's say 90%) SQL hits were cached. I was thinking about CPU context switches but I don't know if that can actually play a significant role. – Antoine Benkemoun May 24 '09 at 13:33
1

For the P part, you could consider opcode caching with i.e. APC. One could also consider mod_fastcgi with php instead of the default mod_php.

Karsten
  • 328
  • 3
  • 11