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

  • 7,528 views
Uploaded on

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

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.

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
7,528
On Slideshare
7,528
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
18
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

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
  • 11. Now we have many choices
  • 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...