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 16. Varnish

Protocols

FastCGI

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

23. SCGI

Simple CGI

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 44. Supports Authorizer role 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 53. Good module selection 54. Same restart advantages 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 64. Benchmark results 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 addmore servers...