We use Amazon Cloudfront for serving all of our static content. The only thing we load from Apache is an index.html file to bootstrap into Ember.js. In our experience, Cloudfront delivers static content to the browser 5-6 times faster than our servers can. So, practically all of our requests serve dynamic content.
Also, I didn't mean that Apache is slow or that it isn't a great web server per say but rather that, due to its single thread per request model, it cannot accept as many concurrent connections as Nginx can. Now, as I have not had time to experiment with Perl+Nginx, I cannot speak to whether or not there are offsetting performance penalties incurred by FCGI. I can tell you that, at some point, I'm going to experiment with it. On Mon, Jun 13, 2016 at 7:16 AM, James Smith <j...@sanger.ac.uk> wrote: > All our experiences at work with nginx/psgi & nginx/fastcgi are poor - it > is very good if any of your queries takes any length of time and/or the > fastcgi/psgi requests are requested a lot relative to the static content > served by nginx then there are quite significant error/performance > issues.... In our case the only static files are mainly images.. The rest > of the content is dynamic - whether it is server cached pages or real > dynamic content... > > We have a load balancing proxy in-front of our apaches so we can fork > content elsewhere that is to be served fast! We don't because Apache itself > is fast enough! Admittedly we have taken a lot of care to reduce the > overall number of requests to a minimum (page, 1 CSS, 1 JS + a handful of > images per page) > > The hacks we would have to do in PSGI/FastCGI to get these features would > probably be negated by the move away from Apache.... > > Apache is fast enough if you use it properly!! > > On 6/13/2016 11:58 AM, John Dunlap wrote: > > Speaking as someone would like to migrate to Nginx, at some point, the big > advantage of Nginx really has nothing to do with mod_perl. It has to do > with Apache. The way Apache processes requests is fundamentally slower than > Nginx and, consequently, Nginx scales better. > On Jun 13, 2016 6:54 AM, "James Smith" <j...@sanger.ac.uk> wrote: > >> Just posted: >> >> mod_perl is a much better framework that PSGI, FastCGI IF you make use of >> the integration of perl into all the stages of apache (you can hook into >> about 15 different stages in the Apache life cycle. >> >> We make of extensive use of the input, output filters, AAA-layers, clean >> up, logging, server startup, etc processes then it is one of the best web >> frameworks you can use. >> >> We have sites where content is produced by either being static, mod_perl, >> php, and java (or proxied back from some ancient CGI software) all >> processed by the same mod_perl code in the output filter to look the same! >> or different if was using a different site! >> >> If all you are interested in is wrapping CGI scripts in a cached >> interpreter for performance then yes you can move to one of these other >> frameworks - but then you have already spent lots of time and effort >> implementing the features that are virtually free with apache/mod_perl! >> >> On 6/11/2016 7:11 PM, Vincent Veyron wrote: >> >> Hi all, >> >> See this post on reddit : >> https://www.reddit.com/r/linuxadmin/comments/4n5seo/apache_22_mod_perl_to_nginx/ >> >> Please help set the record straight. Ancient technology WTF? >> >> >> >> >> >> -- The Wellcome Trust Sanger Institute is operated by Genome Research >> Limited, a charity registered in England with number 1021457 and a company >> registered in England with number 2742969, whose registered office is 215 >> Euston Road, London, NW1 2BE. >> > > > -- The Wellcome Trust Sanger Institute is operated by Genome Research > Limited, a charity registered in England with number 1021457 and a company > registered in England with number 2742969, whose registered office is 215 > Euston Road, London, NW1 2BE. > -- John Dunlap *CTO | Lariat * *Direct:* *j...@lariat.co <j...@lariat.co>* *Customer Service:* 877.268.6667 supp...@lariat.co
