Hello Matt,
÷åòâåðã, 27 àïðåëÿ 2000 ã., you wrote:
>> doing - and the TCP listen queue will hold a few more
>> connections if you are slightly short of backends.
MS> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
I don't think so, at least for "accelerator" applicat
Vivek Khera wrote:
>
> > "DH" == Dave Hodgkinson <[EMAIL PROTECTED]> writes:
>
> DH> I'm currently arguing about this very thing with my BOFH - I think we
> DH> should have, effectively, an SSI apache and a mod_perl apache, he's
>
> I tend to call mod_perl scripts from my SSI's, so it makes
> "GS" == Greg Stark <[EMAIL PROTECTED]> writes:
GS> 3) mod_proxy is poorly designed and poorly implemented. The main
GS>deficiency is that each process is responsible for opening and
GS>maintaining its connection to the backend. This defeats
GS>keep-alives completely and forces
On 29 Apr 2000, Greg Stark wrote:
> Despite these concerns I've been using mod_proxy myself and it does work. I'm
> planning to change to mod_backhand though which implements 3) but it's new
> code.
Let me know how that works out for you. I tried to implement backhand,
but it simply did not hav
Yep all these things are true. Well, the part about being poorly
designed is wrong, it just was designed well, then hacked to death
:-), I guess I'm splitting hairs, but the essential design is easy to
follow. I picked up the entire module in a just a few hours. (I just
think it isn't fair to
A few lessons on this arena:
1) Move your pictures to another server *even if you're using a proxy*
Search back in the archives for my previous post on this topic.
2) If you use mod_proxy you can give it the same web root and have it serve
some static objects itself instead of having to c
> "DH" == Dave Hodgkinson <[EMAIL PROTECTED]> writes:
DH> I'm currently arguing about this very thing with my BOFH - I think we
DH> should have, effectively, an SSI apache and a mod_perl apache, he's
I tend to call mod_perl scripts from my SSI's, so it makes sense for
me to keep them on the
Vivek Khera wrote:
>
> > "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:
>
> >> doing - and the TCP listen queue will hold a few more
> >> connections if you are slightly short of backends.
>
> MS> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
>
> Not being f
On Thu, Apr 27, 2000 at 02:29:15AM +, [EMAIL PROTECTED] wrote:
> Matt & List,
> > Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
> >
>
> This is a good question..., the only answer I've come up with thus far
> from reading the new-httpd devel list is compelling
On Thu, 27 Apr 2000, Matt Sergeant wrote:
> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
There's a big study of proxy servers posted at
http://bakeoff.ircache.net/N02/. There are some expensive ones with
dedicated hardware that perform well. Of course, there are tr
> "MS" == Matt Sergeant <[EMAIL PROTECTED]> writes:
>> doing - and the TCP listen queue will hold a few more
>> connections if you are slightly short of backends.
MS> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
Not being familiar with "Oops", I can say that I
According to Matt Sergeant:
> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
I've run squid as an alternative and did not see any serious
differences except that the caching was defeated about 10% of the
time even on images, apparently because the clients were hitting
> "s" == shane <[EMAIL PROTECTED]> writes:
s> Okay, these are my thoughts, what do you think?
I just set upper bounds on the number of mod_perl processes to be
about 3/4 of RAM based on the size of the typical httpd with
everything loaded, and then I set the maximum number of front-ends to
> Right, but the difference with Oops is it's a threaded server, and while I
> couldn't get it to work (the author appears to be Russian, and his idea of
> documentation is "oops.cfg is easy to understand. Just edit it"), it looks
> like it should be extremely quick, even if serving static images
On Thu, 27 Apr 2000 [EMAIL PROTECTED] wrote:
> Matt & List,
> > Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
> >
>
> This is a good question..., the only answer I've come up with thus far
> from reading the new-httpd devel list is compelling though. Here's
> what
Matt & List,
> Is there any benefit of mod_proxy over a real proxy front end like "Oops"?
>
This is a good question..., the only answer I've come up with thus far
from reading the new-httpd devel list is compelling though. Here's
what people there said in response to folks trying to kill mod_p
On Wed, 26 Apr 2000, Leslie Mikesell wrote:
> According to [EMAIL PROTECTED]:
> >
> > So, overall..., I think that you should consider how many modperl
> > processes you want completely seperately from how many modproxy
> > processes you want.
>
> Apache takes care of these details for you. Al
According to [EMAIL PROTECTED]:
>
> So, overall..., I think that you should consider how many modperl
> processes you want completely seperately from how many modproxy
> processes you want.
Apache takes care of these details for you. All you need to
do is configure MaxClients around the absolut
Modperlers,
Since we've had a little spirited debate on this issue..., I think it
might be nice to go into some detail on this. Well... here are my
ideas.
As Perrin has brought up, if your doing a lot of queries, and that's
the primary focus of your perl scripts, then parallelism is key.
Howeve
19 matches
Mail list logo
