Adding dancer-users back to the thread... Inline... On Wed, Jan 5, 2011 at 1:38 AM, Puneet Kishor <punk.kish@gmail.com> wrote:
Thanks Deepak. A few follow-up questions (others, please feel free to jump in with your wisdom) --
Deepak Gulati wrote:
I run Dancer under Starman and use nginx as a reverse caching proxy. I also let nginx serve most static files (public/images for example) and configure it to gzip the response, add expires headers etc. IMHO Dancer should do what it does best and nginx should do all the other HTTP related heavy-lifting.
Well, Dancer is not a web server. It still needs a web server. When you say that "Dancer should do what it does best and nginx should do all other" stuff, I am assuming what you are trying to say is that Nginx should server all static files, and <Starman> should server all non-static files. (I put <Starman> in <> because one could replace it with another web server).
Indeed. Dancer should do dynamic content. And although there are quite a few capable web-servers that I can use today with plack and run Dancer 'standalone' without putting a web-server in front, I chose this setup because: - I get a lot of things for free with Nginx like caching. - I also get to use the knowledge of the nginx community for common chores like redirecting www.xyz.com to xyz.com. - I get to scale vertically by running multiple dancer instances on different ports or horizontally where one Nginx instance front-ends multiple dancer instances running on different machine - In my setup, I could have done without Starman and run as FCGI but I just found it convenient that I could troubleshoot issues (e.g. to check if my templates got updated while nginx is pushing out cached content) by directly connecting to the Dancer instance on port 5000 through my browser.
My question is thus -- why need two different servers? Can't Nginx do everything? After all, Dancer doesn't serve and content. Dancer creates the content, or routes the web server to the correct content. It is the web server that serves the content. Doesn't having one web server serve static content and the other serve Dancer generated content make your web application more complicated?
I have only one web server right now -- just Apache. If I replace Apache, I want to replace it with something lighter weight, but equally capable, AND, only one program, not multiple programs.
Starman is probably an overkill for my setup.
Why is Starman a probable overkill? Does it consume too many resources?
- It's lightweight enough but I could've just used FCGI since Nginx does all the HTTP front-ending work for me. That said, I too come from a Apache, mod_perl background so these are early days yet.
I run the dancer app using daemontools and the following run script:
#!/bin/sh
export PERL5LIB='/home/ec2-user/TwitterToys/lib' exec 2>&1 \ /usr/local/bin/plackup -s Starman -l 127.0.0.1:5001 -E deployment --workers=10 -a /home/ec2-user/TwitterToys/bin/app.pl
One more question -- Since you are running Starman on port 5001 (as shown above), what would you do for other apps? Would you have to start Starman on a different port for every app that you want to serve? This would mean keeping track of different Starman instances and the ports they were running on.
I haven't given this a thought since I was deploying just one app. But yes, I can see it becoming unmanageable quickly.
Here is a snippet from my nginx config. Hopefully I'll be able to get a detailed step by step write-up out by this weekend.
http { gzip on; gzip_min_length 1024;
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=twitter:8m max_size=64m inactive=60m; proxy_temp_path /tmp; proxy_cache_key "$scheme://$host$request_uri"; proxy_cache_valid 200 60m;
server { server_name stupidtwitterstats.com; listen 80;
location / { proxy_cache twitter; set $do_not_cache 0; if ( $request_uri ~ "^/test$" ) { set $do_not_cache 1; } proxy_no_cache $do_not_cache; proxy_pass http://127.0.0.1:5001; proxy_redirect http://127.0.0.1:5001/ http://$host/; expires 1h; }
location /images/ { alias /home/ec2-user/TwitterToys/public/images/; expires 30d; access_log off; } }
On Tue, Jan 4, 2011 at 10:12 PM, Puneet Kishor<punk.kish@gmail.com> wrote:
I know there are more than one ways to do it, but I have stuck with Apache for three reasons --
- historically Apache has been the front-runner although it may not be anymore;
- at least one of the programs I use utilizes CGI, and I am only familiar with Apache's CGI capabilities; and
- Apache comes installed by default on my computer, my server, and on most all shared web hosting services.
That said, I do have control of my own computer and my server (although no control of the shared service for at least one site). What is, if any, the recommended combination of web servers/proxy servers, etc. that are optimal for Dancer deployment?
The deployment guide does give information on many variations, but, if you, the master dancers, could choose any, what would you choose?
I see a lot of mention of Nginx and Starman, and am considering experimenting with those.
I want speed, ease of installation and configuration, detailed error (and access) logging, and extraction of maximum efficiency with Dancer.
-- Puneet Kishor http://punkish.org Carbon Model http://carbonmodel.org Charter Member, Open Source Geospatial Foundation http://www.osgeo.org Science Fellow http://creativecommons.org/about/people/fellows#puneetkishor Nelson Institute, UW-Madison http://www.nelson.wisc.edu --------------------------------------------------------------------------- Assertions are politics; backing up assertions with evidence is science ===========================================================================