Re: [PHP] Apache to serve RESTful requests using PHP
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
[PHP] Apache to serve RESTful requests using PHP
Dear list, 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? Please let me know your suggestions. Thank you, -behzad
Re: [PHP] Apache to serve RESTful requests using PHP
Bastien Koert On 2013-02-09, at 11:42 AM, AmirBehzad Eslami behzad.esl...@gmail.com wrote: Dear list, 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? Please let me know your suggestions. Thank you, -behzad How much of that data is cachable? You're likely to get bigger performance gains from caching frequent data. Keep-alive at maybe 1 second. But would need to know more about the app to be able to suggest more Bastien -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache to serve RESTful requests using PHP
Bastein, Response is unique per request, and not cachable. The app fetches records from MySQL (say, templates), performs a process on them, and returns the generated output as JSON. We were thinking to use Redis to reduce queries against MySQL, but still Apache will remain as our bottleneck. On Sun, Feb 10, 2013 at 1:00 AM, Bastien phps...@gmail.com wrote: Bastien Koert On 2013-02-09, at 11:42 AM, AmirBehzad Eslami behzad.esl...@gmail.com wrote: Dear list, 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? Please let me know your suggestions. Thank you, -behzad How much of that data is cachable? You're likely to get bigger performance gains from caching frequent data. Keep-alive at maybe 1 second. But would need to know more about the app to be able to suggest more Bastien
Re: [PHP] Apache to serve RESTful requests using PHP
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 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
Re: [PHP] Apache to serve RESTful requests using PHP
On Sat, Feb 9, 2013 at 12:21 PM, Stuart Dallas stu...@3ft9.com wrote: 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. 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. +1 for nginx+php-fpm - the memory savings on this are incredible; while I keep using Apache as a general purpose server, nginx+php-fpm is really ideal for large scale php applications. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Apache to serve RESTful requests using PHP
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. On the other hand, the MySQL's slow_query_log was clear, with long_query_time = 1. Our MySQL database consists of less than 200 records, distributed in normalized tables, yes, queries are making joins, but the overall performance is OK. 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 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. I'm starting to learn more about nginx + php-fpm, thanks for sharing your positive experience about this. -behzad
