4 ms·

"Pancake is a fast, simple and lightweight HTTP-Server written in PHP with acceleration for PHP-powered websites" So...it's written in PHP, so it loads up a PH

by cheald 14y ago

"Pancake is a fast, simple and lightweight HTTP-Server written in PHP with acceleration for PHP-powered websites" So...it's written in PHP, so it loads up a PHP application and serves it faster than running through a real webserver to a PHP backend via FCGI. Duh? Now go ahead and add in high concurrency and static asset serving and add PHP-APC to the workers and don't benchmark on an OpenVZ VM (which doesn't guarantee resources!) and let's see how things shake out. Pancake seems to be touting this "CodeCache", which is great, except that PHP already has APC, which does this already, and I'll wager it does it better. This smells like a false benchmark, where Pancake wins because it's avoiding work that the poorly-configured nginx stack has to do. If you were to tune both of them to their maximum potential, I would be shocked if nginx didn't eat pancake for breakfast.

pp3345 14y ago
I am the developer of Pancake. I've found here after I got a mail saying that Pancake was mentioned here. I have to admit that benchmarking on an OpenVZ VM probably isn't the best idea. However, at the time of benchmarking, my VM was the only one on the host node and I've made sure that no other service on my VM could create high load. I believe that CodeCache is more efficient than APC and easier to use. In a future version I will also improve the CodeCache, allowing more code to be cached than now possible. I am also planning on having a feature for automatic configuration of the CodeCache.
- cheald 14y ago
  Can you do a benchmark demonstrating the performance nginx + php-fpm + APC versus Pancake + CodeCache under high concurrent load, including serving of large (>50kb) assets? Ideally, a benchmark that produces a chart of response time (Y) against concurrency (X) for each product would be great, because "serves one user really fast" is practically worthless for real world purposes. I want to know what the point is at which each server buckles.
- cheald 14y ago
  Well, I was curious and had a bit of free time, so I set up a benchmark. I just used Apache + mod_php with my all-the-extensions-and-the-kitchen-sink PHP install versus Pancake with a pristine PHP install (since it needs special compile flags) and the vhost provided for the nginx benchmark on the Pancake website. Results are here: https://docs.google.com/spreadsheet/ccc?key=0Aqxu-bQf_3O5dFdtT2ZZQUdCbE43X1BSelM3enZYV2c https://docs.google.com/spreadsheet/ccc?key=0Aqxu-bQf_3O5dFd... tl;dr: Pancake falls over completely at higher concurrencies. It even starts dropping requests at -c2, and it just gets worse as concurrency gets higher. I even tried running it with 16 workers rather than 4 (which should cover up through -c9 easily), and it was still failing to return valid results. Pancake's throughput goes up as concurrency goes up, but it's because it's just dropping requests rather than serving them. mod_php easily saturates my two cores with -c2 and remains consistent at ~285 req/sec. Pancake never really achieves better than 90 req/sec, and completely fails to handle high concurrency. Remember, this is Apache and mod_php, which is renowned for being the slow and creaky way to run PHP. If I were to set up nginx and php-fpm, I'm pretty sure I could push that chart even further. I call bull on "faster than nginx".
  - pp3345 14y ago
    Okay, I've taken a look at your benchmark. The failing requests are due to a typo in the configuration. It should be "phpsocketbacklog" instead of just "socketbacklog". Pancake uses unix sockets for the internal communication between RequestWorkers and PHPWorkers. When a RequestWorker tries to send a request to a PHPWorker while the internal socket backlog is full, Pancake will abort the request due to the lack of available resources. Therefore the backlog is needed on high concurrency. I've updated the configuration at pancakehttp.net including some additional performance optimizations. Even though requests won't fail anymore with the fixed configuration, throughput on high concurrency still isn't quite satisfying. This seems to me like a bug as the PHPWorkers seem to process the requests perfectly concurrent and finish each in about the same time, but then the delivery of the result to the client is somehow delayed, probably due to a problem with the internal communication. I've tested Pancake with php-fpm (Pancake supports FastCGI) and high concurrency and it seemed to scale quite good. I'm investigating on this problem and hope to provide a fix soon. Regarding static file throughput, I know that Pancake does not really reach the speed of other webservers here. Pancake was designed to execute PHP as fast as possible and I still have a lot of ideas in my mind on how I could further improve PHP execution speed. PHP itself isn't quite fast and therefore it is difficult to develop a webserver in PHP that reaches the same speed when serving static files as webservers written in languages like C. I am currently experimenting with a new feature that will hopefully increase the speed of static file serving but I still don't know if it'll really work.

by cheald 14y ago

pp3345 14y ago

I am the developer of Pancake. I've found here after I got a mail saying that Pancake was mentioned here. I have to admit that benchmarking on an OpenVZ VM probably isn't the best idea. However, at the time of benchmarking, my VM was the only one on the host node and I've made sure that no other service on my VM could create high load. I believe that CodeCache is more efficient than APC and easier to use. In a future version I will also improve the CodeCache, allowing more code to be cached than now possible. I am also planning on having a feature for automatic configuration of the CodeCache.

cheald 14y ago
Can you do a benchmark demonstrating the performance nginx + php-fpm + APC versus Pancake + CodeCache under high concurrent load, including serving of large (>50kb) assets? Ideally, a benchmark that produces a chart of response time (Y) against concurrency (X) for each product would be great, because "serves one user really fast" is practically worthless for real world purposes. I want to know what the point is at which each server buckles.
cheald 14y ago
Well, I was curious and had a bit of free time, so I set up a benchmark. I just used Apache + mod_php with my all-the-extensions-and-the-kitchen-sink PHP install versus Pancake with a pristine PHP install (since it needs special compile flags) and the vhost provided for the nginx benchmark on the Pancake website. Results are here: https://docs.google.com/spreadsheet/ccc?key=0Aqxu-bQf_3O5dFdtT2ZZQUdCbE43X1BSelM3enZYV2c https://docs.google.com/spreadsheet/ccc?key=0Aqxu-bQf_3O5dFd... tl;dr: Pancake falls over completely at higher concurrencies. It even starts dropping requests at -c2, and it just gets worse as concurrency gets higher. I even tried running it with 16 workers rather than 4 (which should cover up through -c9 easily), and it was still failing to return valid results. Pancake's throughput goes up as concurrency goes up, but it's because it's just dropping requests rather than serving them. mod_php easily saturates my two cores with -c2 and remains consistent at ~285 req/sec. Pancake never really achieves better than 90 req/sec, and completely fails to handle high concurrency. Remember, this is Apache and mod_php, which is renowned for being the slow and creaky way to run PHP. If I were to set up nginx and php-fpm, I'm pretty sure I could push that chart even further. I call bull on "faster than nginx".
- pp3345 14y ago
  Okay, I've taken a look at your benchmark. The failing requests are due to a typo in the configuration. It should be "phpsocketbacklog" instead of just "socketbacklog". Pancake uses unix sockets for the internal communication between RequestWorkers and PHPWorkers. When a RequestWorker tries to send a request to a PHPWorker while the internal socket backlog is full, Pancake will abort the request due to the lack of available resources. Therefore the backlog is needed on high concurrency. I've updated the configuration at pancakehttp.net including some additional performance optimizations. Even though requests won't fail anymore with the fixed configuration, throughput on high concurrency still isn't quite satisfying. This seems to me like a bug as the PHPWorkers seem to process the requests perfectly concurrent and finish each in about the same time, but then the delivery of the result to the client is somehow delayed, probably due to a problem with the internal communication. I've tested Pancake with php-fpm (Pancake supports FastCGI) and high concurrency and it seemed to scale quite good. I'm investigating on this problem and hope to provide a fix soon. Regarding static file throughput, I know that Pancake does not really reach the speed of other webservers here. Pancake was designed to execute PHP as fast as possible and I still have a lot of ideas in my mind on how I could further improve PHP execution speed. PHP itself isn't quite fast and therefore it is difficult to develop a webserver in PHP that reaches the same speed when serving static files as webservers written in languages like C. I am currently experimenting with a new feature that will hopefully increase the speed of static file serving but I still don't know if it'll really work.