Re: mod_proxy_balancer/mod_proxy_ajp TODO

2006-06-20 Thread Mladen Turk
Henri Gomez wrote: Important point in load balancing will be to collect CPU load (job load) from the remote. We often make the mistake to split requests between servers as if it cost the same CPU power (or cpu load) for each of them, but in Java / J2EE some requests could be more CPU/IO/DB

Trouble with the bundled PCRE

2006-06-20 Thread Ivan Ristic
I have a problem with the bundled PCRE that I am not sure how to resolve. Basically, in a module I need to access more functionality than provided by the Apache PCRE wrapper. (More specifically, I need to perform matching against strings that are not NULL-terminated.) I can do this if I have the

Re: mod_proxy_balancer/mod_proxy_ajp TODO

2006-06-20 Thread Cheenu
I have had a need for this functionality in one application or other for a while now and have been researching various means of acheiving it without actually coding.mod_backhand ( www.backhand.org) which seems to be an abandoned project was very promising a few years back.I think, section 3.3 of

Re: debug apache

2006-06-20 Thread Alexander Lazic
On Mon 19.06.2006 07:07, Jeff Trawick wrote: If httpd *developers* are interested, we should decide what type of processing is acceptable/required first and worry about whether it can be fitted into apr second. As I recall from the last discussion of this perhaps 15 months ago, most all of the

Re: Trouble with the bundled PCRE

2006-06-20 Thread Joe Orton
On Tue, Jun 20, 2006 at 11:39:29AM +0100, Ivan Ristic wrote: I have a problem with the bundled PCRE that I am not sure how to resolve. Basically, in a module I need to access more functionality than provided by the Apache PCRE wrapper. (More specifically, I need to perform matching against

[Patch 39806] Add env vars to mod_proxy_balancer to allow more control

2006-06-20 Thread Brian Rectanus
Hello all, I have a minor patch to mod_proxy_balancer that I would like to get applied. The patch adds some environment vars to balancer requests to export info on the chosen route so that it possible to control sticky sessions entirely from the reverse proxy instead of modifying the backend

RE: Question on multi-process CGID

2006-06-20 Thread Mendonce, Kiran (STSD)
It depends on where the real bottleneck is. Most of the time, if you are unable to cope with the volume of incoming CGI requests, its because your CGIs themselves are slow to start. For example, if your CGIs are coded in Perl, just starting them can take a long time, which is independent of

Re: debug apache

2006-06-20 Thread Jeff Trawick
On 6/20/06, Alexander Lazic [EMAIL PROTECTED] wrote: On Mon 19.06.2006 07:07, Jeff Trawick wrote: If httpd *developers* are interested, we should decide what type of processing is acceptable/required first and worry about whether it can be fitted into apr second. As I recall from the last

Re: [Patch 39806] Add env vars to mod_proxy_balancer to allow more control

2006-06-20 Thread Jeff Trawick
On 6/20/06, Brian Rectanus [EMAIL PROTECTED] wrote: I have a minor patch to mod_proxy_balancer that I would like to get applied. The patch adds some environment vars to balancer requests to export info on the chosen route so that it possible to control sticky sessions entirely from the reverse

Re: [Patch 39806] Add env vars to mod_proxy_balancer to allow more control

2006-06-20 Thread Ruediger Pluem
On 06/20/2006 08:17 PM, Jeff Trawick wrote: On 6/20/06, Brian Rectanus [EMAIL PROTECTED] wrote: I have a minor patch to mod_proxy_balancer that I would like to get applied. The patch adds some environment vars to balancer requests to export info on the chosen route so that it possible to

Re: Question on multi-process CGID

2006-06-20 Thread Paul Querna
Mendonce, Kiran (STSD) wrote: It depends on where the real bottleneck is. Most of the time, if you are unable to cope with the volume of incoming CGI requests, its because your CGIs themselves are slow to start. For example, if your CGIs are coded in Perl, just starting them can take a

RE: Question on multi-process CGID

2006-06-20 Thread Mendonce, Kiran (STSD)
I am looking into the probable bottlenecks. Agreed that the worker MPM has its advantages. But for a customer who is being asked to move to Apache 2.0, we are falling short on the performance and that makes it hard to sell. Since worker + mod_cgid was supposed to improve performance, how is it

RE: Question on multi-process CGID

2006-06-20 Thread Mendonce, Kiran (STSD)
We tried using mod_cgi with worker. And its very slow. So that's not an option we have. Currently we have only worker MPM supported on HP-UX which is why I tried the multiple cgid approach. I went through some of the archived discussions to see if anybody had experienced something similar.

Re: Question on multi-process CGID

2006-06-20 Thread Paul Querna
Mendonce, Kiran (STSD) wrote: We tried using mod_cgi with worker. And its very slow. So that's not an option we have. Currently we have only worker MPM supported on HP-UX which is why I tried the multiple cgid approach. Ah. Now it makes sense. My experiences with this have only been on

Re: debug apache

2006-06-20 Thread William A. Rowe, Jr.
Jeff Trawick wrote: On 6/20/06, Alexander Lazic [EMAIL PROTECTED] wrote: On Mon 19.06.2006 07:07, Jeff Trawick wrote: If httpd *developers* are interested, we should decide what type of processing is acceptable/required first and worry about whether it can be fitted into apr second. As I