Choosing a Web Architecture for Perl
- 1. Choosing a Web Architecture for Perl Perrin Harkins We Also Walk Dogs
- 2. This used to be an easy decision Netscape, or Apache for you hippies
- 3. CGI, or NSAPI if you enjoy core dumps
- 4. Server-side development matured, and it stayed easy Apache became the standard web server
- 5. mod_perl became the way to run Perl
- 6. FastCGI was looking peaky Outside of Amazon's reality distortion field anyway
- 7. Then two things happened Ruby came along Renewed interest in FastCGI
- 8. Thanks, Ruby! Non-blocking I/O became fashionable Memcached
- 9. Lighttpd
- 10. Nginx
- 11. Now we have many choices Web servers Apache
- 12. Lighttpd
- 13. Nginx
- 14. Squid
- 15. Perlbal
- 17. HTTP
- 18. SCGI
- 19. FastCGI Many implementations for different servers
- 20. Daemons are managed by the web server or an external process
- 21. Has hooks for auth, logging, and filtering, but not always implemented and rarely used
- 22. HTTP Reverse proxy forwards HTTP requests to apache/mod_perl backend
- 24. Stealing good ideas from Python
- 25. Simpler than FastCGI, so theoretically could be faster
- 26. The graveyard of alternative Perl daemons SpeedyCGI
- 27. PersistentPerl
- 28. Both replace the #! line and daemonize your program
- 29. Biases Long-time mod_perl contributor
- 30. Member of Apache Software Foundation Don't believe a word I say!
- 31. Apache 2.2 mod_proxy + mod_perl Frontend apache runs threaded worker MPM
- 32. Backend apache runs prefork MPM
- 33. All popular apache modules (mod_ssl, mod_rewrite, mod_security, mod_deflate, caching, auth) are available
- 34. mod_proxy_balancer provides load balancing
- 35. Apache 2.2 mod_fastcgi Frontend runs threaded worker MPM
- 36. As with mod_proxy, all popular apache modules are available
- 37. Three poorly-named configurations: ”Static” starts a set number of procs at server startup
- 38. ”Dynamic” starts a new proc every time it gets a request up to a configured limit
- 39. ”Standalone” sends requests to daemon you start
- 40. Apache 2.2 mod_fastcgi Can run separate versions of same package name in separate daemons True for mod_perl too if you run multiple backends, but less obvious Seamless restart for code upgrades in standalone mode Start a new set of procs on same socket and shut down the old ones
- 41. Could get close with two mod_perl backends, but not simple
- 42. Lighttpd mod_fastcgi Non-blocking I/O server
- 43. Supports static and standalone FastCGI
- 45. Solid selection of modules with equivalents of most popular apache ones
- 46. Same restart advantages as FastCGI on Apache
- 47. Load balancing across FastCGI daemons
- 48. Lighttpd mod_scgi Same Lighttpd, different protocol
- 49. Sketchy docs
- 50. nginx FastCGI Another non-blocking I/O server
- 51. Supports standalone FastCGI only
- 52. Does not support Authorizer role
- 55. nginx proxy + mod_perl Load balancing
- 56. What about running naked mod_perl? Static requests
- 57. Buffering for slow clients
- 58. Keep-Alive
- 59. Benchmark methodology Very simple Catalyst app Sleeps for 0.1 seconds
- 60. Returns 35K of HTML (perl.com homepage) Brief run of ab (Apache Bench) with intended concurrency to warm up server
- 61. ab tests at concurrency of 10, 50, 150, 200
- 62. General findings FastCGI static mode is difficult to use with apache/mod_fastcgi Trial and error to find magic number
- 63. Worked better with Lighttpd FastCGI standalone mode is unusable on Lighttpd Load balancing feature marks daemons as down if they're too busy to answer right away and rejects requests SCGI Perl implementations incomplete
- 65. Not really apples to apples mod_perl does other things
- 66. Filters on non-perl content (PHP, etc.)
- 67. Customize server and request phases
- 68. Replace HTTP with your own protocol Apache 2 + mod_perl 2 is a server kit
- 69. Thanks! And please help me add more servers...