This document discusses deploying Plack web applications. It begins with an overview of the PSGI specification and how it allows various web frameworks like Catalyst and Dancer to run on different web servers through a common interface. It then discusses various options for the server environment including standalone HTTP servers like Starman and FastCGI servers. Finally, it covers useful Plack middleware for application environments, including modules for rate limiting, caching, authentication, and more.
37. HTTP::Server::PSGI
• Plack Built-in
• Pure Perl
• Single-process, cross platform
• Experimental IPv6, SSL
• Automatic reloading with -r
Great for development and testing
38. HTTP::Server::Simple::PSGI
• Zero non-core dependencies (other than
HTTP::Server::Simple)
• Single-process, extensible with H::S::S
• Works on 5.005_*
• Dancer’s default web server
39. HTTP::Server::Simple::PSGI
• Zero non-core dependencies (other than
HTTP::Server::Simple)
• Single-process, extensible with H::S::S
• Works on 5.005_*
• Dancer’s default web server
Great for embedding e.g. Android
41. CGI
• Plack::Handler::CGI
• Almost universally available
• Quite slow and inefficient
• Reasonably easy to run from the shell
Last resort for Win32/IIS
laptop web apps
43. mod_perl
• Plack::Handler::Apache[12]
• Lots of hooks and Apache modules
• Porting from mod_perl to PSGI might be
tricky. (There are some tools/attempts)
Not recommended unless you’ve
hugely invested in mod_perl
44. Perlbal::Plugin::PSGI
• Pure perl load balancer
• LiveJournal, TypePad etc.
• Reproxying, Plugins etc.
• Danga::Socket (non-blocking)
45. Perlbal::Plugin::PSGI
• Pure perl load balancer
• LiveJournal, TypePad etc.
• Reproxying, Plugins etc.
• Danga::Socket (non-blocking)
Considered EXPERIMENTAL
46. mod_psgi
• Apache module to run PSGI apps
• No mod_perl hooks
• Just persistent PSGI apps
• Simpler
47. mod_psgi
• Apache module to run PSGI apps
• No mod_perl hooks
• Just persistent PSGI apps
• Simpler
Considered EXPERIMENTAL
66. uWSGI
• FastCGI-like protocol
• Optimized for *SGI
• built-in nginx/cherokee support
• AnyEvent support in the works
• Lots of configurations
• harakiri mode
75. HTTP Standalone☺
• Put it behind frontend (nginx, lighttpd)
• Most web servers support reverse proxy
• As well as load balancers (perlbal, varnish)
• Easy for human to debug and test
• nginx + unix socket workers work well
76. HTTP Standalone ☹
• You may have to configure X-Forwarded-*
and ReverseProxy middleware
• Keep-alives can be problematic in dumb
servers like mod_proxy on apache2
• Path mismatch on frontend/backend could
cause headaches
77. FastCGI ☺
• Many web servers support fastcgi
• No need for X-Forwarded-* configuration
• Potentially faster binary protocol between
web server and app server
• “Hot deploy” via UNIX sockets
78. FastCGI ☹
• Binary protocol, may not be easy to debug
• Requires C/XS (but see fastpass)
• Hard to get SCRIPT_NAME/PATH_INFO
right (e.g. lighttpd, mod_fcgid)