On 10 Feb 2013, at 06:57, AmirBehzad Eslami <behzad.esl...@gmail.com> wrote:
> Stuart, thanks for your detailed response. > > >> I find it unlikely that Apache is your bottleneck, > >> especially with a service involving MySQL. > >> How have you come to this conclusion? > > Apache is the entry-point to our service, and I did a > benchmark with AB to see how it can handle concurrent > requests in a timely fashion. After a number of 50 concurrent > requests, the average "time per request" reached from less than > a second to 5 seconds. I *strongly* recommend you try the same test with nginx. Unless this is due to the way your code works I'm confident you'll see this effect disappear! > >> As far as keep-alive goes, how frequently will individual > >> clients be accessing the service? > > There are only "a few" clients that call the service. These clients > are PHP-driven web pages. Each page has its own unique ClickID > and a set of other unique parameters per user visit. These pages send these > parameters to the service using php-curl, and expect a generated > response to be returned. That's why I'm saying each request and > response is unique. > > Whenever a user visits a web-page, there would be a call to the > web-service. At the moment, we don't know number of concurrent > visits. We're looking for a way to figure that out in Apache. > > Is there a way to see if the requests are using the previously keep-alived > http channel? Because same client will send requests to the service, > and I'm curious to know if the Apache will allocate the already-opened > channel, or will create a new one? If it's making one request to your service per page request, keep-alive is pointless as it won't be able to reuse the connection. In this instance I would turn keep-alive off. > >> 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. > > Memcache or Redis, I'm going to add a caching layer between > MySQL and PHP, to store the de-normilized data. For simple caching I'd recommend Memcache over Redis, purely because Redis is more complex due to its support for sets, queues and other very useful stuff. The only reason I'd use Redis for simple caching is because it can periodically flush the cache to disk so if it has to restart it can start with a primed cache. However, in most cases that is not a huge advantage. If each request and response is unique you need to be careful about what you choose to cache such that you don't incur caching costs without reaping benefits that make it worthwhile. -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
