On 9 Feb 2013, at 16:42, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote:

> We're a developing a PHP-driven web service with a RESTful API,
> and we have a dedicated Linux server for that with 6GB of RAM.
> Since this service will be used by many clients in a concurrent
> manner,  we'll face with a high-load on our web-server.  But
> web-services are different from web pages, for instance they
> don't include images, or in this case we only serve JSON.
> I'm wondering what are the recommended configurations for
> the Apache web-server in these situations?  Should we disable
> keep-avlie?  What about other directives?  Apache is our
> bottleneck, and we're trying to optimize it. Should we use nginx instead?

I find it unlikely that Apache is your bottleneck, especially with a service 
involving MySQL. How have you come to this conclusion?

I would personally recommend nginx + php-fpm over Apache + mod-php every time. 
The pre-request memory footprint is massively reduced and I've seen nothing but 
upsides since migrating most of my client's sites, and my own.

As far as keep-alive goes, how frequently will individual clients be accessing 
the service? Are they likely to be using client software that supports 
keep-alive? You basically want to weigh up the cost of potentially keeping the 
connection open against the likelihood that the majority of clients will make 
use of it for multiple requests. My gut reaction based on your description 
would be to set it to 1 as suggested by Bastien so it has minimal impact while 
still allowing clients who support it to be that bit more efficient.

Focus your optimisation efforts on MySQL. If the bulk of requests will be reads 
you'll benefit from read-only slaves. If the data can be neatly sharded then 
that's definitely worth investigating. When writing data get it as close to the 
structure that will be needed when reading, including de-normalising it if 

If you are using joins to pull in extra data (i.e. IDs to a name or similar) 
look at using Memcache for those, but make sure that when they're updated in 
the DB they're also updated in Memcache. Do the DB query, get all the Memcache 
keys you need a do a multi-get request. The other way to do this is to 
de-normalise as discussed above, but that makes updating the data very 
expensive (as every row needs to be updated). In my tests breaking it out to a 
Memcache instance was far more efficient.

At the end of the day there will always be things you can do that are only 
applicable to your service, but the general rule is to need to do as little as 
possible to serve the data when it's requested, shifting as much of the work as 
possible to when it is written (assuming a mostly-read service).


Stuart Dallas
3ft9 Ltd

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to