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
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
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
>
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
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
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
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/...
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
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
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
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
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
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.
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 wrote:
> Hi all,
>
> See this post on reddit :
>
>
>
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
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
16 matches
Mail list logo