This talk was presented at OSCON 2009 and YAPC::NA 2009. The choices discussed here are still relevant, although Plack has opened up some new options. For a more up-to-date take on this material I would recommend Tatsuhiko Miyagawa's most recent Plack/PSGI talks.

1. Choosing a Web Architecture for Perl Perrin Harkins We Also Walk Dogs

3. CGI, or NSAPI if you enjoy core dumps

5. mod_perl became the way to run Perl

9. Lighttpd

10. Nginx

12. Lighttpd

13. Nginx

14. Squid

15. Perlbal

17. HTTP

18. SCGI

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

24. Stealing good ideas from Python

25. Simpler than FastCGI, so theoretically could be faster

27. PersistentPerl

28. Both replace the #! line and daemonize your program

30. Member of Apache Software Foundation Don't believe a word I say!

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

36. As with mod_proxy, all popular apache modules are available

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

41. Could get close with two mod_perl backends, but not simple

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

49. Sketchy docs

51. Supports standalone FastCGI only

52. Does not support Authorizer role

53. Good module selection

54. Same restart advantages

57. Buffering for slow clients

58. Keep-Alive

61. ab tests at concurrency of 10, 50, 150, 200

64. Benchmark results

66. Filters on non-perl content (PHP, etc.)

67. Customize server and request phases

69. Thanks! And please help me add more servers...