2

I have an Ubuntu server running apache2 which i expect to be hit by around 500-1000 (concurent) users for a limited amount of time. The server serves a mixture of custom (rather light) php pages connected to a postgresql db (around 20 Mb in size) and static content. The hardware is stable and pretty beefy:

  • Intel Xeon E5420 @ 2.5 GHz
  • 12 GB RAM

During previous rushes on this server I have increased ServerLimit, the MaxClients for the MPM modules and decreased Timeout and KeepAliveTimeout. It has worked, but been sluggish and I have a feeling more can be done. How would you suggest configuring the Apache server to handle this kind of load?

Improve this question
2
  • 1
    when you say "light" php - how light is light - can you add some code to get some page rendering times out of the code. even something that takes 0.5 seconds to render for a single user translates to a significant load when dealing with 1000 users. As a typical rule of thumb for generic applications we set the maximum concurrent sessions per server as 300, we setup VM's with 1 vCPU and gb RAM and then load balance. This is something you could do on your current hardware without too many issues. It could also be that your saturating your network link.
    – Geraint Jones
    May 31, 2010 at 9:11
  • Rendering time of heavy pages is typically less than 0.1 seconds. Network link is not congested (we peak less than 10Mbit on a 100Mbit link). Would multipe instances with a virtualization layer and load balancer really give better performance than just tuning a single apache server?
    – pehrs
    May 31, 2010 at 11:28

2 Answers 2

Reset to default
3

Your bottleneck in this scenario will be the PHP and what it's doing with the database. If you are opening up a new connection with each call, then you're more than likely going to hit I/O walls on the disk access more than anything else. Your best bet is to have the database and static content in a RAM disk and commit changes as needed to the database on disk. Also maintain an efficient query caching mechanism using a RAM-dedicated fast hash lookup in the PHP so that you don't burden postgresql with unnecessary processing cycles related to query cache lookups. Although postgresql is likely to be more efficient in query caching than your own code, it's not as fast as never needing to be connected to in the first place.

Improve this answer
-3

Your server should be able to handle things easily. Just a few notes:

  1. Using SSL will increase your computational requirements. So, use plain HTTP.
  2. Using prefork MPM will increase your memory requirements. So, use worker MPM.
  3. Using more concurrency with more cores will improve performance.
  4. Dedicate more RAM to your PostgreSQL database.

These are just generic guidelines.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .