Choosing a Web Architecture for Perl
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Choosing a Web Architecture for Perl

on

  • 7,331 views

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

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.

Statistics

Views

Total Views
7,331
Views on SlideShare
7,331
Embed Views
0

Actions

Likes
0
Downloads
18
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Choosing a Web Architecture for Perl Presentation Transcript

  • 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 add more servers...