Here Be Dragons: PHP at Its Limits.

PHP application frameworks come with many well known benefits. The Request-Response structure exposed by many of these frameworks also gives us the opportunity to reduce overheads in our applications significantly. By using PHPFastCGI and the Speedfony Bundle - you can take a simple application from 250 rq/s to over 2200 rq/s. This talk gives a brief overview of the process, the dragons and the rewards.

Transcript

1. Here Be Dragons PHP at Its Limits Presentation by Andrew Carter @AndrewCarterUK http://github.com/AndrewCarterUK http://github.com/PHPFastCGI
2. What do we need for a web application? • We need a web server – something to serve our application to the outside world • Our application is a 'function'. It takes an input and produces an output... Response = F ( Request ) • We need some way to write this 'function' and tell our web server about it!
3. CGI: Common Gateway Interface • When a request comes in, a program is started with a series of environment variables REQUEST_URI, REQUEST_METHOD, SERVER_ADDR, ... • What the executable prints out is sent as the response • At least one new process per request • Can use any language to make our application
4. CGI and PHP • Originally PHP was a CGI program • Server modules are now more common • Even with 'mod_php', each apache worker thread needs to load the PHP interpreter • Enter FastCGI...
5. • FastCGI applications run as a server/daemon. • FastCGI applications receive the same variables and send the same response as a CGI application - but over a local connection. • One process can handle many requests!
6. PHP-FPM • PHP-FPM uses FastCGI • Don't need to load the PHP interpreter for each request • But PHP still has to reload our application for each request. We can do better...
7. Legacy PHP Applications How could we 'daemonize' this script? We could use output buffering? But it's hard to see how a third party piece of software could do this without a fixed application structure...
8. Request-Response Frameworks How could we 'daemonize' this script? All we need to do is set up the kernel, create a 'Request' object for each request and relay the returned response.
9. Dragons!!! Can you think of any dangers?
10. Dragon #1 • PHP isn't designed to live for very long • Applications tend to be quite careless about memory allocation • Long running PHP scripts need to be supervised – consider restarting process after 'N' requests have been served
11. Dragon #2 • Static memory is now shared between requests • Previously all the memory accessible from our application was limited to the current request scope • This is no longer true – we have to be very careful about static memory and application state
12. PHPFastCGI – A collection of packages... • FastCGIDaemon Listens for FastCGI requests Listens for FastCGI requests • SpeedfonyBundle Integrates the FastCGIDaemon with symfony2 • SpeedfonyBenchmarkingApp Simple site for speed testing
13. An alternative: PHP-PM
14. PHPFastCGI vs. PHP-PM • Both not yet stable – don't even think about going near them in production! • FastCGI applications can be process managed by the web server... can restart our workers without the web server sending out 5XX error messages • Easier to put FastCGI applications on a shared server
15. Benchmarks 1 2 3 4 5 10 15 20 0 500 1000 1500 2000 2500 PHP-FPM PHP-PM PHPFastCGI Concurrent connections Requests per second VMWare Fusion: Ubuntu 15.04 (64 bit), 4 cores, 2 GB RAM, NGINX
16. The Future & PSR-7 • PHP extensions and web server modules could make this process a lot easier! • PSR-7: Standard 'Request' and 'Response' objects allow for FastCGIDaemon and similar packages to become framework agnostic
17. Thank you for listening! Any questions? Presentation by Andrew Carter @AndrewCarterUK http://github.com/AndrewCarterUK http://github.com/PHPFastCGI