Mailing List Archive

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.

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" <js5@sanger.ac.uk
> <mailto:js5@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.

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 <js5@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" <js5@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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

I invited him to stop by for help understanding what he's got running and
what his options are. He doesn't know perl, so this is probably all a black
box to him.

On Sat, Jun 11, 2016 at 2:11 PM, Vincent Veyron <vv.lists@wanadoo.fr> 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?
>
>
> --
> Bien à vous, Vincent Veyron
>
> https://libremen.com
> Logiciels de gestion, libres
>

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 <js5@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" <js5@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.
>>
>
>
>

I think you might consider HTTP/2 as a method that could deliver faster
because yes, you can have multiple threads processing for data return per
socket simultaneously.


On Tue, Jun 14, 2016 at 2:35 AM, André Warnier <aw@ice-sa.com> wrote:

> 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 <js5@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" <js5@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.
>>>
>>>
>>
>>
>>
>


--
Dog approved this message.

https://www.nginx.com/blog/nginx-vs-apache-our-view/

On Tue, Jun 14, 2016 at 2:35 AM, André Warnier <aw@ice-sa.com> wrote:

> 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 <js5@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" <js5@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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

On 6/14/2016 3:28 PM, John Dunlap wrote:
> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>
Unfortunately for us we actually use some of those 500 things that
apache is good at, that nginx doesn't do:

* Making use of all the handler/filter hooks in apache;
* Fronting a complex web-application, where requests by definition
take a long time to return (the databases and related queries are
complex)





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

As mentioned in this article, nginx is a great reverse proxy for mod_perl
sites.

On Tue, Jun 14, 2016 at 10:28 AM, John Dunlap <john@lariat.co> wrote:

> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>
> On Tue, Jun 14, 2016 at 2:35 AM, André Warnier <aw@ice-sa.com> wrote:
>
>> 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 <js5@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" <js5@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:*
> *john@lariat.co <john@lariat.co>*
>
> *Customer Service:*
> 877.268.6667
> support@lariat.co
>

We don't use any of those hooks into Apache. mod_perl invokes our main
handler and, from there, we do everything ourselves. We even built our own
authentication and authorization mechanisms, directly into our application,
instead of relying on Apache to provide them. We've contained all mod_perl
specific code to 2-3 files so that we have more freedom to decide how and
where our application will be deployed.

On Tue, Jun 14, 2016 at 10:37 AM, James Smith <js5@sanger.ac.uk> wrote:

>
> On 6/14/2016 3:28 PM, John Dunlap wrote:
>
> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>
> Unfortunately for us we actually use some of those 500 things that apache
> is good at, that nginx doesn't do:
>
> - Making use of all the handler/filter hooks in apache;
> - Fronting a complex web-application, where requests by definition
> take a long time to return (the databases and related queries are complex)
>
>
>
> -- 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

We have multiple apps, and we just switch in and out our auth/page
wrapper/logging/debugging code as we need to, if some one else comes up
with an app we tell them what they do to get the information and "jobs a
good-un", much simpler than having multiple embedded
login/authentication/... methods... We know because other projects use
the style frameworks you are talking about - and we go you just XYZ, and
then realize that they are using some nginx/psgi/starman solution and
have to go - aargh - no you can't just do that - you will have to
re-engineer your app!

James

On 6/14/2016 3:40 PM, John Dunlap wrote:
> We don't use any of those hooks into Apache. mod_perl invokes our main
> handler and, from there, we do everything ourselves. We even built our
> own authentication and authorization mechanisms, directly into our
> application, instead of relying on Apache to provide them. We've
> contained all mod_perl specific code to 2-3 files so that we have more
> freedom to decide how and where our application will be deployed.
>
> On Tue, Jun 14, 2016 at 10:37 AM, James Smith <js5@sanger.ac.uk
> <mailto:js5@sanger.ac.uk>> wrote:
>
>
> On 6/14/2016 3:28 PM, John Dunlap wrote:
>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>
> Unfortunately for us we actually use some of those 500 things that
> apache is good at, that nginx doesn't do:
>
> * Making use of all the handler/filter hooks in apache;
> * Fronting a complex web-application, where requests by
> definition take a long time to return (the databases and
> related queries are complex)
>
>
>
> -- 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:*/
> /john@lariat.co <mailto:john@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <mailto:support@lariat.co>




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

Nah, we don't do that either. All of our stuff is written in perl and
anything that gets built gets built within our architecture. There's no
duplication.

On Tue, Jun 14, 2016 at 10:48 AM, James Smith <js5@sanger.ac.uk> wrote:

> We have multiple apps, and we just switch in and out our auth/page
> wrapper/logging/debugging code as we need to, if some one else comes up
> with an app we tell them what they do to get the information and "jobs a
> good-un", much simpler than having multiple embedded
> login/authentication/... methods... We know because other projects use the
> style frameworks you are talking about - and we go you just XYZ, and then
> realize that they are using some nginx/psgi/starman solution and have to go
> - aargh - no you can't just do that - you will have to re-engineer your app!
>
> James
> On 6/14/2016 3:40 PM, John Dunlap wrote:
>
> We don't use any of those hooks into Apache. mod_perl invokes our main
> handler and, from there, we do everything ourselves. We even built our own
> authentication and authorization mechanisms, directly into our application,
> instead of relying on Apache to provide them. We've contained all mod_perl
> specific code to 2-3 files so that we have more freedom to decide how and
> where our application will be deployed.
>
> On Tue, Jun 14, 2016 at 10:37 AM, James Smith <js5@sanger.ac.uk> wrote:
>
>>
>> On 6/14/2016 3:28 PM, John Dunlap wrote:
>>
>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>
>> Unfortunately for us we actually use some of those 500 things that apache
>> is good at, that nginx doesn't do:
>>
>> - Making use of all the handler/filter hooks in apache;
>> - Fronting a complex web-application, where requests by definition
>> take a long time to return (the databases and related queries are complex)
>>
>>
>>
>> -- 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:*
> * <john@lariat.co>john@lariat.co <john@lariat.co>*
>
> * Customer Service:*
> 877.268.6667
> <support@lariat.co>support@lariat.co
>
>
>
> -- 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

Though, if you have no control over what apps you have to support and they
are wirtten in multiple architectures... I can totally see where you're
coming from.

On Tue, Jun 14, 2016 at 10:48 AM, James Smith <js5@sanger.ac.uk> wrote:

> We have multiple apps, and we just switch in and out our auth/page
> wrapper/logging/debugging code as we need to, if some one else comes up
> with an app we tell them what they do to get the information and "jobs a
> good-un", much simpler than having multiple embedded
> login/authentication/... methods... We know because other projects use the
> style frameworks you are talking about - and we go you just XYZ, and then
> realize that they are using some nginx/psgi/starman solution and have to go
> - aargh - no you can't just do that - you will have to re-engineer your app!
>
> James
> On 6/14/2016 3:40 PM, John Dunlap wrote:
>
> We don't use any of those hooks into Apache. mod_perl invokes our main
> handler and, from there, we do everything ourselves. We even built our own
> authentication and authorization mechanisms, directly into our application,
> instead of relying on Apache to provide them. We've contained all mod_perl
> specific code to 2-3 files so that we have more freedom to decide how and
> where our application will be deployed.
>
> On Tue, Jun 14, 2016 at 10:37 AM, James Smith <js5@sanger.ac.uk> wrote:
>
>>
>> On 6/14/2016 3:28 PM, John Dunlap wrote:
>>
>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>
>> Unfortunately for us we actually use some of those 500 things that apache
>> is good at, that nginx doesn't do:
>>
>> - Making use of all the handler/filter hooks in apache;
>> - Fronting a complex web-application, where requests by definition
>> take a long time to return (the databases and related queries are complex)
>>
>>
>>
>> -- 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:*
> * <john@lariat.co>john@lariat.co <john@lariat.co>*
>
> * Customer Service:*
> 877.268.6667
> <support@lariat.co>support@lariat.co
>
>
>
> -- 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

We have upwards over 200 people creating content and services - in
differening frameworks, languages ... on the current servers we maintain
in mod_perl the last count we had about 30-40 developers writing perl
code over probably 30 or 40 different applications within the same
cluster of webservers....

James

On 6/14/2016 3:52 PM, John Dunlap wrote:
> Though, if you have no control over what apps you have to support and
> they are wirtten in multiple architectures... I can totally see where
> you're coming from.
>
> On Tue, Jun 14, 2016 at 10:48 AM, James Smith <js5@sanger.ac.uk
> <mailto:js5@sanger.ac.uk>> wrote:
>
> We have multiple apps, and we just switch in and out our auth/page
> wrapper/logging/debugging code as we need to, if some one else
> comes up with an app we tell them what they do to get the
> information and "jobs a good-un", much simpler than having
> multiple embedded login/authentication/... methods... We know
> because other projects use the style frameworks you are talking
> about - and we go you just XYZ, and then realize that they are
> using some nginx/psgi/starman solution and have to go - aargh - no
> you can't just do that - you will have to re-engineer your app!
>
> James
>
> On 6/14/2016 3:40 PM, John Dunlap wrote:
>> We don't use any of those hooks into Apache. mod_perl invokes our
>> main handler and, from there, we do everything ourselves. We even
>> built our own authentication and authorization mechanisms,
>> directly into our application, instead of relying on Apache to
>> provide them. We've contained all mod_perl specific code to 2-3
>> files so that we have more freedom to decide how and where our
>> application will be deployed.
>>
>> On Tue, Jun 14, 2016 at 10:37 AM, James Smith <js5@sanger.ac.uk
>> <mailto:js5@sanger.ac.uk>> wrote:
>>
>>
>> On 6/14/2016 3:28 PM, John Dunlap wrote:
>>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>>
>> Unfortunately for us we actually use some of those 500 things
>> that apache is good at, that nginx doesn't do:
>>
>> * Making use of all the handler/filter hooks in apache;
>> * Fronting a complex web-application, where requests by
>> definition take a long time to return (the databases and
>> related queries are complex)
>>
>>
>>
>> -- 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:*/
>> /john@lariat.co <mailto:john@lariat.co>/
>> /
>> *Customer Service:*/
>> 877.268.6667
>> support@lariat.co <mailto:support@lariat.co>
>
>
> -- 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:*/
> /john@lariat.co <mailto:john@lariat.co>/
> /
> *Customer Service:*/
> 877.268.6667
> support@lariat.co <mailto:support@lariat.co>




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

Sounds like you're making the right choice for your organization then. Our
company is considerably smaller and we only build/maintain a single app.

On Tue, Jun 14, 2016 at 11:04 AM, James Smith <js5@sanger.ac.uk> wrote:

> We have upwards over 200 people creating content and services - in
> differening frameworks, languages ... on the current servers we maintain in
> mod_perl the last count we had about 30-40 developers writing perl code
> over probably 30 or 40 different applications within the same cluster of
> webservers....
> James
>
>
> On 6/14/2016 3:52 PM, John Dunlap wrote:
>
> Though, if you have no control over what apps you have to support and they
> are wirtten in multiple architectures... I can totally see where you're
> coming from.
>
> On Tue, Jun 14, 2016 at 10:48 AM, James Smith <js5@sanger.ac.uk> wrote:
>
>> We have multiple apps, and we just switch in and out our auth/page
>> wrapper/logging/debugging code as we need to, if some one else comes up
>> with an app we tell them what they do to get the information and "jobs a
>> good-un", much simpler than having multiple embedded
>> login/authentication/... methods... We know because other projects use the
>> style frameworks you are talking about - and we go you just XYZ, and then
>> realize that they are using some nginx/psgi/starman solution and have to go
>> - aargh - no you can't just do that - you will have to re-engineer your app!
>>
>> James
>> On 6/14/2016 3:40 PM, John Dunlap wrote:
>>
>> We don't use any of those hooks into Apache. mod_perl invokes our main
>> handler and, from there, we do everything ourselves. We even built our own
>> authentication and authorization mechanisms, directly into our application,
>> instead of relying on Apache to provide them. We've contained all mod_perl
>> specific code to 2-3 files so that we have more freedom to decide how and
>> where our application will be deployed.
>>
>> On Tue, Jun 14, 2016 at 10:37 AM, James Smith < <js5@sanger.ac.uk>
>> js5@sanger.ac.uk> wrote:
>>
>>>
>>> On 6/14/2016 3:28 PM, John Dunlap wrote:
>>>
>>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>>
>>> Unfortunately for us we actually use some of those 500 things that
>>> apache is good at, that nginx doesn't do:
>>>
>>> - Making use of all the handler/filter hooks in apache;
>>> - Fronting a complex web-application, where requests by definition
>>> take a long time to return (the databases and related queries are complex)
>>>
>>>
>>>
>>> -- 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:*
>> * <john@lariat.co>john@lariat.co <john@lariat.co>*
>>
>> * Customer Service:*
>> 877.268.6667
>> <support@lariat.co>support@lariat.co
>>
>>
>>
>> -- 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:*
> * <john@lariat.co>john@lariat.co <john@lariat.co>*
>
> * Customer Service:*
> 877.268.6667
> <support@lariat.co>support@lariat.co
>
>
>
> -- 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:*
*john@lariat.co <john@lariat.co>*

*Customer Service:*
877.268.6667
support@lariat.co

I was considering nginx for a reverse project I had awhile back. At the time there wasn't any support for SSO modules. Like for siteminder or ping federate. So I had to stick with Apache. Not sure if that is still the caseros not.

Sent from my iPhone

> On Jun 14, 2016, at 9:28 AM, John Dunlap <john@lariat.co> wrote:
>
> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>
>> On Tue, Jun 14, 2016 at 2:35 AM, André Warnier <aw@ice-sa.com> wrote:
>>> 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 <js5@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" <js5@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:
> john@lariat.co
>
> Customer Service:
> 877.268.6667
> support@lariat.co
> <100x60.png>

On 06/14/2016 11:04 AM, James Smith wrote:
> We have upwards over 200 people creating content and services - in differening
> frameworks, languages ... on the current servers we maintain in mod_perl the
> last count we had about 30-40 developers writing perl code over probably 30 or
> 40 different applications within the same cluster of webservers....


This is good to hear. I wish I knew of companies working with modperl
in NYC


>
> James
>
> On 6/14/2016 3:52 PM, John Dunlap wrote:
>> Though, if you have no control over what apps you have to support and they are
>> wirtten in multiple architectures... I can totally see where you're coming from.
>>
>> On Tue, Jun 14, 2016 at 10:48 AM, James Smith <js5@sanger.ac.uk
>> <mailto:js5@sanger.ac.uk>> wrote:
>>
>> We have multiple apps, and we just switch in and out our auth/page
>> wrapper/logging/debugging code as we need to, if some one else comes up
>> with an app we tell them what they do to get the information and "jobs a
>> good-un", much simpler than having multiple embedded
>> login/authentication/... methods... We know because other projects use the
>> style frameworks you are talking about - and we go you just XYZ, and then
>> realize that they are using some nginx/psgi/starman solution and have to
>> go - aargh - no you can't just do that - you will have to re-engineer your
>> app!
>>
>> James
>>
>> On 6/14/2016 3:40 PM, John Dunlap wrote:
>>> We don't use any of those hooks into Apache. mod_perl invokes our main
>>> handler and, from there, we do everything ourselves. We even built our
>>> own authentication and authorization mechanisms, directly into our
>>> application, instead of relying on Apache to provide them. We've
>>> contained all mod_perl specific code to 2-3 files so that we have more
>>> freedom to decide how and where our application will be deployed.
>>>
>>> On Tue, Jun 14, 2016 at 10:37 AM, James Smith
>>> <<mailto:js5@sanger.ac.uk>js5@sanger.ac.uk> wrote:
>>>
>>>
>>> On 6/14/2016 3:28 PM, John Dunlap wrote:
>>>> https://www.nginx.com/blog/nginx-vs-apache-our-view/
>>>>
>>> Unfortunately for us we actually use some of those 500 things that
>>> apache is good at, that nginx doesn't do:
>>>
>>> * Making use of all the handler/filter hooks in apache;
>>> * Fronting a complex web-application, where requests by definition
>>> take a long time to return (the databases and related queries are
>>> complex)
>>>
>>>
>>>
>>> -- 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:*/
>>> /<mailto:john@lariat.co>john@lariat.co/
>>> /
>>> *Customer Service:*/
>>> 877.268.6667
>>> <mailto:support@lariat.co>support@lariat.co
>>
>>
>> -- 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:*/
>> /<mailto:john@lariat.co>john@lariat.co/
>> /
>> *Customer Service:*/
>> 877.268.6667
>> <mailto:support@lariat.co>support@lariat.co
>
>
> -- 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.
>


--
So many immigrant groups have swept through our town
that Brooklyn, like Atlantis, reaches mythological
proportions in the mind of the world - RI Safir 1998
http://www.mrbrklyn.com

DRM is THEFT - We are the STAKEHOLDERS - RI Safir 2002
http://www.nylxs.com - Leadership Development in Free Software
http://www2.mrbrklyn.com/resources - Unpublished Archive
http://www.coinhangout.com - coins!
http://www.brooklyn-living.com

Being so tracked is for FARM ANIMALS and and extermination camps,
but incompatible with living as a free human being. -RI Safir 2013