Re: Bad rap

2016-06-14 Thread Ruben Safir
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

Re: Bad rap

2016-06-14 Thread Hiram Gibbard
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

Re: Bad rap

2016-06-14 Thread John Dunlap
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 wrote: > We have upwards over 200 people creating content and services - in >

Re: Bad rap

2016-06-14 Thread James Smith
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

Re: Bad rap

2016-06-14 Thread John Dunlap
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 wrote: > We have multiple apps, and we just switch in and out our

Re: Bad rap

2016-06-14 Thread John Dunlap
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 wrote: > We have multiple apps, and we just switch in and out our auth/page

Re: Bad rap

2016-06-14 Thread James Smith
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/...

Re: Bad rap

2016-06-14 Thread John Dunlap
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

Re: Bad rap

2016-06-14 Thread Perrin Harkins
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 wrote: > https://www.nginx.com/blog/nginx-vs-apache-our-view/ > > On Tue, Jun 14, 2016 at 2:35 AM, André Warnier wrote: > >> On

Re: Bad rap

2016-06-14 Thread James Smith
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

Re: Bad rap

2016-06-14 Thread John Dunlap
https://www.nginx.com/blog/nginx-vs-apache-our-view/ On Tue, Jun 14, 2016 at 2:35 AM, André Warnier 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

Re: Bad rap

2016-06-14 Thread Skylos
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 wrote: > On 13.06.2016 14:09, John Dunlap wrote: > >> We use

Re: Bad rap

2016-06-14 Thread André Warnier
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.