On 13.06.2016 14:09, John Dunlap wrote:
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,
does anyone do better ? multiple threads per request ? some new kind of parallel quantum
computing ?
Sorry, I guess you meant something else, but in this case maybe it helps to be
precise ?
(or, I am willng to learn if there is a model which I don't know yet)
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.
