On 9 Feb 2013, at 16:42, AmirBehzad Eslami <behzad.eslami@xxxxxxxxx> 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 necessary. 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 -- Stuart Dallas 3ft9 Ltd http://3ft9.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
