Slashdot Mirror


Optimize PHP and Accelerate Apache

An anonymous reader writes "As the load on an application increases, the bottlenecks in the underlying infrastructure become more apparent in the form of slow response to user requests. This article discusses many of the server configuration items that can make or break an application's performance and focuses on steps you can take to optimize Apache and PHP."

14 of 191 comments (clear)

  1. Of course! by BabaYama · · Score: 5, Funny

    You should compile it yourself wicked fast compiler optimizations on top of your wicked fast install of Gentoo (which you also compiled yourself)

    --
    Sucks
  2. Diet article by billcopc · · Score: 5, Informative

    Maybe I'm being a cynical bastard again, but that article is REEEALLY light on content. Compared to the other featured articles from IBM, which are usually very rich and informative, this one is more like an "idiots guide to apache", the kind that belongs on Digg's mountain of filth. This is little more than a rehash of the Readme files for Apache and PHP combined. It's about as deep as telling a windows user how to make their PC faster by changing to the Windows NT theme. Of much greater value to web professionals is this article from a fellow OSDN site (!) Lighttpd can lighten Apache's load

    --
    -Billco, Fnarg.com
  3. http is the problem by larry+bagina · · Score: 5, Funny

    Last year, we dumped apache (and http altogether) and went with a gopherd/fastcgi approach for serving up our php pages. For people still stuck on port 80, we have a squid proxy which converts the request to gopher. Since then, traffic has increased 34%, while average load has dropped by 20%.

    --
    Do you even lift?

    These aren't the 'roids you're looking for.

  4. Re:want performance from php? by gbjbaanb · · Score: 4, Insightful

    They are for static content.

    Now lighttpd serves 6 out of the top 250 sites. Do you think the other 246 run IIS or something?

    Lighttpd is good, but is best used in specialised instances, for specific (mainly static content) tasks. Its pointless using it for PHP as the cost of forking out a process to run the script will outweigh any saving from running a lighter-weight http server.

  5. Apache ain't the fastest... by Anonymous Coward · · Score: 4, Informative

    It's common knowledge that Apache certainly isn't the fastest out there to server web pages. For static pages lighttpd and, heck, even a basic stand-alone Tomcat (yup, a Java server!) can easily serve as many pages as Apache. That was already the case for, say, Java 1.5 / Tomcat 5.5. Now take Java 1.6 and Tomcat 6 (or, better, Resin [not completely free]) and suddenly Apache is looking even more ridiculous.

    For anything SSL related IIS makes fun of Apache.

    For many concurrent sessions there are proof of concept servers written in functional languages (like erlang) that handle an order of magnitude (!) more simultaneous sessions than what Apache does.

    I understand that for many here Apache is all they know and hence regard it as the holy grail but it is far, far, from being that. It is a good overall purpose web server but it is certainly not the fastest.

    In the face of the countless security holes that are all too common in C-written apps I'm now more and more installing pure Java web servers. At first I was using Apache + Tomcat now I'm more and more using Tomcat in standalone mode. Easier configuration, no buffer overflows to patch.

  6. Re:want performance from php? by doubledjd · · Score: 5, Informative
    My history is java but I've come to appreciate php recently. The track record on it when used properly is impressive. In case there are some people just starting with it, the several of the problems with php performance is caching. (this is pretty standard stuff so apoligies to people who know a lot more about it than I do)
    1. Use apc or eaccelerator. (yahoo uses apc so that is the one we went with). This alone will give considerable benefit. Apc can defaultly cache any of the php that runs or it can also be used as a local cache for objects you'd like to store programmatically.
    2. If you need distributed items, especially in a non-sticky load balanced environment, look at memcached.
    3. Use a query cache for your db
    4. If your db connections are expensive, look at sqlrelay
    5. Look at whether a caching proxy is a possibility for you (squid or apache has some mods).
    6. Benchmark your pages and functions. It is the only way to know if configuration tweaks are adding any value. I usually do this after a full profiling using apd (to help identify the bottlenecks and frequently called functions). I usually run apache's ab to get a look at page benchmarks.
    7. you can always write c extensions for items in php that are too slow. Of course, you'll have to know c, increased maintenance, development time, etc
    There are a million things to be done to increase performance. Obviously, don't use anything blindly. Still, I think the opcode cache (apc or eAccelerator) is probably the easiest and most substantial win.
  7. Re:You can talk about this all day, but... by tomhudson · · Score: 4, Informative

    "I also expect that the language is going to be forked at some point unless the PHP developers clean up the function naming - it's infuriating."

    There's nothing to stop you from cleaning up the function naming. We'd all appreciate it :-)

    Also, if you really want performance "uber alles", don't bother with apache or any other "pre-made" server - write a custom server in c designed to load modules that serve just the content you want served. You can then handle a thousand requests per second (including time to access the database a half-dozen times per request) on comodity hardware.

    Its not like there isn't code out there that shows you how to implement a server in c, how to write and load modules in c, how to use threads in c, and how to access mysql via c. You'll be super fast ... except that your development time will be super slow.

    apache+php is a compromose that most people can live with, most of the time.

    Yes, the function naming in php is crap. Show us a scripting language where it isn't.

  8. Re:want performance from php? by consumer · · Score: 5, Informative

    All that apache does when serving PHP requests with mod_php is run the early phases (auth, URL mapping) and pass the request to PHP. Do you really think that Lighttpd + FastCGI is going to be significantly faster than that? The bottleneck is your PHP code, not the web server.



    Lighttpd is probably faster at serving static content. Most sites don't have enough bandwidth to find out.

  9. Re:want performance from php? by malsdavis · · Score: 5, Insightful

    "PHP is slower than Perl or Python for most stuff."

    I'd say that in practice (i.e. when performing the vast majority of dynamic web functionality: e.g. database lookups) the opposite is true. Perl & Python are quicker at some tasks, but every-time I've rewritten a website between PHP and Perl (I don't program in Python because it's named after my most hated animal), PHP has come out slightly on top.

  10. Re:want performance from php? by SQL+Error · · Score: 5, Insightful

    The problem is not that Apache is slow, it's that it uses huge amounts of memory. If your database is running slow for some reason - say, during backups - requests will start to queue up, Apache will start more and more threads to handle those requests, and things will spiral rapidly out of control.

    Lightppd doesn't have that problem.

  11. Performance tuning and optimization of LAMP by kbahey · · Score: 4, Informative
    This is a set of articles on Drupal performance tuning and optimization for large web sites. Although it says Drupal, much of it applies to the LAMP stack in general.

    It includes:

    • PHP op-code caches / accelerators: Drupal large site case study
    • Benchmarking APC vs. eAccelerator using Drupal
    • Drupal core caching and contributed content caching modules
    • Installing eAccelerator 0.9.5.1 on Ubuntu Feisty 7.04
    • logwatcher: restart Apache after a segmentation fault
    • MySQL InnoDB: performance gains as well as some pitfalls
    • MySQL my.cnf configuration for a large Drupal site
    • Presentation: Performance tuning and optimization of high traffic Drupal sites
    • Tools for Performance Tuning and Optimization
    • Tuning the Apache MaxClients parameter
    • Links and resources on Drupal performance tuning and optimization


    Disclaimer: this is stuff that I have written.
  12. Re:want performance from php? by consumer · · Score: 4, Interesting

    If you use separate processes for your static content and your PHP (either Apache with FastCGI or a reverse proxy), you won't have problems with memory. The size of an Apache process that's just serving static stuff is tiny. It's the PHP processes that take the RAM, and they will do the same when run from Lighttpd.

  13. Re:want performance from php? by Anonymous Coward · · Score: 5, Funny

    Dear Opera user: Fuck you.

  14. The real way to improve server performance... by dgym · · Score: 5, Funny
    ...is to decrease load on the server. Most of the work can be done on the client anyway, so that is where it belongs.

    Here are a few tips:
    • Databases can get pretty slow with complicated queries, so upload your database to the client when they load the page and then your database queries are distributed.
    • PHP isn't very fast, and neither are Perl or Python, so you don't want to be running them on the server either. Write an interpreter for the language of your choice in Javascript and move your business logic to the client. This will also interface better with the client side database copy.
    • SSL is a performance killer, don't use it. If you need to send something securely just prefix it with a predetermined number of random letters and numbers, no one will think to look beyond them.
    • Writing to databases can be pretty bad too. Try discarding all your changes, your users might not notice the difference, but they will appreciate the performance gain.
    • Even with all the above you might still be getting too many requests. Try designing your site to exploit bugs in the major browsers and reconfigure your users machine to store and load everything itself.
    • Get better hardware.
    • Make your site less interesting, or less reliable. Changing your DNS entry to point to an unrelated site for one week a month can really help reduce load.
    • If you have had success with the other steps then you don't need a dynamic server anymore, code a simple static server in assembly, preferably for the architecture you intend to be running on, and be done with it.

    Best of luck!