You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Mladen Turk <mt...@apache.org> on 2004/08/11 18:14:34 UTC
[proxy] New implementation ready for testing
Hi all,
We've finished the initial development of extended mod_proxy.
Since the development took place at jakata-tomcat-connectors,
the source code can be found under ajp/proxy.
Here is the list of major features added:
1. AJP13 protocol support
2. Connection pool for threaded servers
3. Added new module proxy_balancer
4. Added mod_status extended information hook.
Connection pool:
The connection pool enables reusing backend connections
and was build around apr_reslist. At the moment only the
proxy_ajp extensively uses this connection pool, with
performance slightly better then mod_jk.
Http module also uses connection pool, but only to the
level of skipping DNS lookup, and shows around 20% performance
boost over the current implementation.
Ftp module although uses the connection pool will need more
testing.
proxy_balancer:
The new proxy balancer is capable to balance the load trough
the cluster of backend server. For the moment the implemented
algorithm is based on the preset dispatch factor, counting
the number of connections processed on each node.
It can mix the protocols so one can make a cluster containing
the http, ajp and ftp backends, although the usability of such
configuration is questionable.
TODO:
1. Testing
2. Bugfixing
3. finish AJP13 (ssl + resend)
P.S.
I'll be on vacation for the next two weeks, and unreachable by
the standard electronic devices.
Regards,
MT.
Re: [proxy] New implementation ready for testing
Posted by Henri Gomez <hg...@apache.org>.
William A. Rowe, Jr. wrote:
> At 11:14 AM 8/11/2004, Mladen Turk wrote:
>
>
>>The connection pool enables reusing backend connections
>>and was build around apr_reslist. At the moment only the
>>proxy_ajp extensively uses this connection pool, with
>>performance slightly better then mod_jk.
>
>
> I noticed one huge win - unless I'm misreading... we don't require
> any includes from j2sdk/include/ ??? That in and of itself is great :)
No need for java include since ajp implementation is the one using
network support, no jni involved :)
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:14 AM 8/11/2004, Mladen Turk wrote:
>The connection pool enables reusing backend connections
>and was build around apr_reslist. At the moment only the
>proxy_ajp extensively uses this connection pool, with
>performance slightly better then mod_jk.
I noticed one huge win - unless I'm misreading... we don't require
any includes from j2sdk/include/ ??? That in and of itself is great :)
Bill
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> Since it will take some time to assess that the changes and new features
> are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy
> into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after
> its very slow crawl to some measure of stability. So count me a pretty
> strong -1 for backporting any major refactoring of proxy for 2.0.
>
> You know what pain it took for proxy to be accepted as useful (v.s. 1.3).
>
> This is a pretty significant leap, so it really doesn't make that much sense
> to compromise things.
I see your point... In that case I'm now keen to see httpd v2.2 go out
the door. :)
One of the side effects of this work is that the connection pool and
load balancing code is available to proxy_http as well as proxy_ajp,
which means a performance boost to the HTTP proxy.
The main reason I was keen to see an RPM spec file in the official
release was to make it easy for people to use our most recent versions
out in the real world, instead of vendor supplied more conservative
releases (especially releases minus the experimental modules). It would
be cool to see packaging for Debian, or Solaris, etc added as well. This
would make it easy for people to deploy our latest releases without
being forced to wait for the more conservative vendors to catch up, and
in turn get httpd 2.2 onto more servers.
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:37 PM 8/11/2004, William A. Rowe, Jr. wrote:
>At 01:03 PM 8/11/2004, Graham Leggett wrote:
>>
>>My plan is to start bringing it into httpd v2.1 from next week, assessing
>>how hard the backports to httpd v2.0 would potentially be. Is the history
>>kept in the tomcat connector tree enough, or is it critical to get the full
>>history into httpd HEAD?
>
>If it weren't critical, the Apache Group would still be kicking around patch
>files and tarballs :)
<sarcasm=off/>
This has been committed with full history retained (dropping a few backed-out
patches.)
>I'm looking at the mechanics of moving this already.
This is done. Don't make me hurt you for causing more development on
the jakarta-tomcat-connectors/ajp/proxy/ fork!!! Please blast that branch
into the attic before someone sends my blood pressure through the roof
(again :)
Graham, please commit those patches from ajp developers as needed
(for the time being.) Remember 2.0-HEAD is C-T-R.
I've protected the -I ./ajp within the --enable-proxy-ajp feature, and fixed
for broken vpath builds. What about adding a -with-ajp=/path/to/ajp
feature, which would enable the proxy-ajp based on the --enable-proxy
setting? As it stands with my commits, ajp is disabled unless
explicitly enabled (due to the ajplib dependency.) I have no problems
if we also add ajp* sources to either modules/proxy itself, or bury it
in apr-util (should be brought up with the dev@apr list.)
Bill
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:37 PM 8/11/2004, William A. Rowe, Jr. wrote:
>At 01:03 PM 8/11/2004, Graham Leggett wrote:
>>
>>My plan is to start bringing it into httpd v2.1 from next week, assessing
>>how hard the backports to httpd v2.0 would potentially be. Is the history
>>kept in the tomcat connector tree enough, or is it critical to get the full
>>history into httpd HEAD?
>
>If it weren't critical, the Apache Group would still be kicking around patch
>files and tarballs :)
<sarcasm=off/>
This has been committed with full history retained (dropping a few backed-out
patches.)
>I'm looking at the mechanics of moving this already.
This is done. Don't make me hurt you for causing more development on
the jakarta-tomcat-connectors/ajp/proxy/ fork!!! Please blast that branch
into the attic before someone sends my blood pressure through the roof
(again :)
Graham, please commit those patches from ajp developers as needed
(for the time being.) Remember 2.0-HEAD is C-T-R.
I've protected the -I ./ajp within the --enable-proxy-ajp feature, and fixed
for broken vpath builds. What about adding a -with-ajp=/path/to/ajp
feature, which would enable the proxy-ajp based on the --enable-proxy
setting? As it stands with my commits, ajp is disabled unless
explicitly enabled (due to the ajplib dependency.) I have no problems
if we also add ajp* sources to either modules/proxy itself, or bury it
in apr-util (should be brought up with the dev@apr list.)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> Since it will take some time to assess that the changes and new features
> are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy
> into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after
> its very slow crawl to some measure of stability. So count me a pretty
> strong -1 for backporting any major refactoring of proxy for 2.0.
>
> You know what pain it took for proxy to be accepted as useful (v.s. 1.3).
>
> This is a pretty significant leap, so it really doesn't make that much sense
> to compromise things.
I see your point... In that case I'm now keen to see httpd v2.2 go out
the door. :)
One of the side effects of this work is that the connection pool and
load balancing code is available to proxy_http as well as proxy_ajp,
which means a performance boost to the HTTP proxy.
The main reason I was keen to see an RPM spec file in the official
release was to make it easy for people to use our most recent versions
out in the real world, instead of vendor supplied more conservative
releases (especially releases minus the experimental modules). It would
be cool to see packaging for Debian, or Solaris, etc added as well. This
would make it easy for people to deploy our latest releases without
being forced to wait for the more conservative vendors to catch up, and
in turn get httpd 2.2 onto more servers.
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:03 PM 8/11/2004, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>>That's something of a shame, because we lose the development
>>history importing the finished effort, and it was further disappointing
>>that you didn't bring across the earlier cvs history so this branch
>>could be brought back into httpd/modules/proxy with a complete
>>history.
>
>Ideally though I personally would like to see proxy_ajp in httpd v2.0 (assuming it's practical, which could only be assessed once proxy_ajp existed). Getting it into a working form first, then getting it into v2.1, and then backporting it in clean logical sections to http v2.0 means it may be possible to get it into httpd v2.0, without small bugfix commits getting in the way.
Since it will take some time to assess that the changes and new features
are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy
into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after
its very slow crawl to some measure of stability. So count me a pretty
strong -1 for backporting any major refactoring of proxy for 2.0.
You know what pain it took for proxy to be accepted as useful (v.s. 1.3).
This is a pretty significant leap, so it really doesn't make that much sense
to compromise things.
>>I'm actually very excited that we can offer in the 2.2 release - this
>>really rocks. What you accomplished is very cool!
>>I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise.
>>Boo :(
>
>My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD?
If it weren't critical, the Apache Group would still be kicking around patch
files and tarballs :)
I'm looking at the mechanics of moving this already.
2.1-dev stays C-T-R just to avoid this sort of mess and encourage new
contributions. If folks would focus on adding the new wiz-bang stuff to
2.1-dev, and not obsess over backports, 2.2 would already be out the
door, IMHO :)
Obviously, if there were no other way, it would be a no-brainer that some
2.0 feature (or separate downloadable patch) would be appropriate. It
wouldn't be a stretch to have a little conditional #if APR_MAJOR < 1
logic to offer backwards compatibility, then an end user could build their
httpd with the 2.1-dev proxy tree instead of the 2.0 flavor.
But with both _jk and _jk2, there are options - this is simply a monumental
improvement over the old way. That's why versions exist in the first place :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
Graham Leggett wrote:
> William A. Rowe, Jr. wrote:
>> I'm actually very excited that we can offer in the 2.2 release - this
>> really rocks. What you accomplished is very cool!
>> I'm entirely +1 today for bringing it back into modules/proxy/ (it's a
>> c-t-r branch.) How you did it makes this a non-trivial exercise. Boo :(
>
>
> My plan is to start bringing it into httpd v2.1 from next week,
> assessing how hard the backports to httpd v2.0 would potentially be. Is
> the history kept in the tomcat connector tree enough, or is it critical
> to get the full history into httpd HEAD?
>
The sources in the ajp/proxy already have all thats needed
for backporting.
I'm actually using 2.0.50 for testing (with scoreboard patch),
although it works and without that patc, only the balancer in that
case convolves to the correct behavior statistically.
Regards,
MT.
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 01:03 PM 8/11/2004, Graham Leggett wrote:
>William A. Rowe, Jr. wrote:
>
>>That's something of a shame, because we lose the development
>>history importing the finished effort, and it was further disappointing
>>that you didn't bring across the earlier cvs history so this branch
>>could be brought back into httpd/modules/proxy with a complete
>>history.
>
>Ideally though I personally would like to see proxy_ajp in httpd v2.0 (assuming it's practical, which could only be assessed once proxy_ajp existed). Getting it into a working form first, then getting it into v2.1, and then backporting it in clean logical sections to http v2.0 means it may be possible to get it into httpd v2.0, without small bugfix commits getting in the way.
Since it will take some time to assess that the changes and new features
are stable, v.s. dev quality, I believe it's sorta pointless to put extra energy
into the 2.0 backport. We won't compromise mod_proxy again in 2.0 after
its very slow crawl to some measure of stability. So count me a pretty
strong -1 for backporting any major refactoring of proxy for 2.0.
You know what pain it took for proxy to be accepted as useful (v.s. 1.3).
This is a pretty significant leap, so it really doesn't make that much sense
to compromise things.
>>I'm actually very excited that we can offer in the 2.2 release - this
>>really rocks. What you accomplished is very cool!
>>I'm entirely +1 today for bringing it back into modules/proxy/ (it's a c-t-r branch.) How you did it makes this a non-trivial exercise.
>>Boo :(
>
>My plan is to start bringing it into httpd v2.1 from next week, assessing how hard the backports to httpd v2.0 would potentially be. Is the history kept in the tomcat connector tree enough, or is it critical to get the full history into httpd HEAD?
If it weren't critical, the Apache Group would still be kicking around patch
files and tarballs :)
I'm looking at the mechanics of moving this already.
2.1-dev stays C-T-R just to avoid this sort of mess and encourage new
contributions. If folks would focus on adding the new wiz-bang stuff to
2.1-dev, and not obsess over backports, 2.2 would already be out the
door, IMHO :)
Obviously, if there were no other way, it would be a no-brainer that some
2.0 feature (or separate downloadable patch) would be appropriate. It
wouldn't be a stretch to have a little conditional #if APR_MAJOR < 1
logic to offer backwards compatibility, then an end user could build their
httpd with the 2.1-dev proxy tree instead of the 2.0 flavor.
But with both _jk and _jk2, there are options - this is simply a monumental
improvement over the old way. That's why versions exist in the first place :)
Bill
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> That's something of a shame, because we lose the development
> history importing the finished effort, and it was further disappointing
> that you didn't bring across the earlier cvs history so this branch
> could be brought back into httpd/modules/proxy with a complete
> history.
Ideally though I personally would like to see proxy_ajp in httpd v2.0
(assuming it's practical, which could only be assessed once proxy_ajp
existed). Getting it into a working form first, then getting it into
v2.1, and then backporting it in clean logical sections to http v2.0
means it may be possible to get it into httpd v2.0, without small bugfix
commits getting in the way.
> I'm actually very excited that we can offer in the 2.2 release - this
> really rocks. What you accomplished is very cool!
>
> I'm entirely +1 today for bringing it back into modules/proxy/ (it's
> a c-t-r branch.) How you did it makes this a non-trivial exercise.
> Boo :(
My plan is to start bringing it into httpd v2.1 from next week,
assessing how hard the backports to httpd v2.0 would potentially be. Is
the history kept in the tomcat connector tree enough, or is it critical
to get the full history into httpd HEAD?
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
William A. Rowe, Jr. wrote:
> That's something of a shame, because we lose the development
> history importing the finished effort, and it was further disappointing
> that you didn't bring across the earlier cvs history so this branch
> could be brought back into httpd/modules/proxy with a complete
> history.
Ideally though I personally would like to see proxy_ajp in httpd v2.0
(assuming it's practical, which could only be assessed once proxy_ajp
existed). Getting it into a working form first, then getting it into
v2.1, and then backporting it in clean logical sections to http v2.0
means it may be possible to get it into httpd v2.0, without small bugfix
commits getting in the way.
> I'm actually very excited that we can offer in the 2.2 release - this
> really rocks. What you accomplished is very cool!
>
> I'm entirely +1 today for bringing it back into modules/proxy/ (it's
> a c-t-r branch.) How you did it makes this a non-trivial exercise.
> Boo :(
My plan is to start bringing it into httpd v2.1 from next week,
assessing how hard the backports to httpd v2.0 would potentially be. Is
the history kept in the tomcat connector tree enough, or is it critical
to get the full history into httpd HEAD?
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Mladen Turk wrote:
> Since we are (Henri and myself, not sure for JeanFrederic) not
> httpd commiters, I'm not sure how the proxy_ajp will get maintained,
> but we can always send patches :)
I'm quite happy to maintain the code, and can chase up any patches you
send through in the mean time, if others don't beat me to it.
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
>>Never cross my mind that we'll need all those try-error-fix
>>commits back on the httpd cvs tree.
>
>
> We actually like those - the next individual to say "wow - this fix is easy!"
> can go back over history and say "grumf - they tried that in the first place"
>
> :)
>
> Question...
> ajp_header.lo ajp_link.lo ajp_msg.lo
>
> are all required by proxy_ajp
Sure, they are all needed.
> any thoughts on how those
> will be kept in-sync or what folks should do to obtain?
>
Have no idea.
I was thinking that we leave the ajplib sources at j-t-c,
so they can be copied over to /srclib or directly inside
/modules/proxy/ajp when something major happens.
We have discussed to add the compression and security
support for ajp (AJP14 extensions), and also make the
server side code (only the packet menagement API).
All that was agreed on tomcat-dev prior we start coding.
Since we are (Henri and myself, not sure for JeanFrederic) not
httpd commiters, I'm not sure how the proxy_ajp will get maintained,
but we can always send patches :)
Regards,
MT.
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 12:54 PM 8/11/2004, you wrote:
>Never cross my mind that we'll need all those try-error-fix
>commits back on the httpd cvs tree.
We actually like those - the next individual to say "wow - this fix is easy!"
can go back over history and say "grumf - they tried that in the first place"
:)
Question...
ajp_header.lo ajp_link.lo ajp_msg.lo
are all required by proxy_ajp - any thoughts on how those
will be kept in-sync or what folks should do to obtain?
Bill
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
>>We've finished the initial development of extended mod_proxy.
>>Since the development took place at jakata-tomcat-connectors,
>>the source code can be found under ajp/proxy.
>
> I'm entirely +1 today for bringing it back into modules/proxy/ (it's
> a c-t-r branch.) How you did it makes this a non-trivial exercise.
> Boo :(
>
Mea culpa :(
Never cross my mind that we'll need all those try-error-fix
commits back on the httpd cvs tree.
Regards,
MT.
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
William A. Rowe, Jr. wrote:
>
>>We've finished the initial development of extended mod_proxy.
>>Since the development took place at jakata-tomcat-connectors,
>>the source code can be found under ajp/proxy.
>
> I'm entirely +1 today for bringing it back into modules/proxy/ (it's
> a c-t-r branch.) How you did it makes this a non-trivial exercise.
> Boo :(
>
Mea culpa :(
Never cross my mind that we'll need all those try-error-fix
commits back on the httpd cvs tree.
Regards,
MT.
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:14 AM 8/11/2004, Mladen Turk wrote:
>We've finished the initial development of extended mod_proxy.
>Since the development took place at jakata-tomcat-connectors,
>the source code can be found under ajp/proxy.
That's something of a shame, because we lose the development
history importing the finished effort, and it was further disappointing
that you didn't bring across the earlier cvs history so this branch
could be brought back into httpd/modules/proxy with a complete
history.
I'm actually very excited that we can offer in the 2.2 release - this
really rocks. What you accomplished is very cool!
I'm entirely +1 today for bringing it back into modules/proxy/ (it's
a c-t-r branch.) How you did it makes this a non-trivial exercise.
Boo :(
(Sorry my earlier responses only seem to have hit httpd-dev, due to
trashcan'ned moderation and my list-receipt email differing from my
-accept from account differing.)
Bill
Re: [proxy] New implementation ready for testing
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 16 Aug 2004, at 12:49, jean-frederic clere wrote:
> Pier Fumagalli wrote:
>> On 11 Aug 2004, at 17:14, Mladen Turk wrote:
>>> Hi all,
>>>
>>> We've finished the initial development of extended mod_proxy.
>>> Since the development took place at jakata-tomcat-connectors,
>>> the source code can be found under ajp/proxy.
>>>
>>> Here is the list of major features added:
>>> 3. Added new module proxy_balancer
>> What's wrong with:
>
> - http is slower than ajp (Therefore the idea of mod_proxy_ajp).
Although I don't agree in the AJP protocol, I see the point...
> - failover.
That's a good point! :-P +1
Pier
Re: [proxy] New implementation ready for testing
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Pier Fumagalli wrote:
> On 11 Aug 2004, at 17:14, Mladen Turk wrote:
>
>> Hi all,
>>
>> We've finished the initial development of extended mod_proxy.
>> Since the development took place at jakata-tomcat-connectors,
>> the source code can be found under ajp/proxy.
>>
>> Here is the list of major features added:
>> 3. Added new module proxy_balancer
>
>
> What's wrong with:
- http is slower than ajp (Therefore the idea of mod_proxy_ajp).
- failover.
Cheers
Jean-Frederic
>
> ProxyPassReverse / http://localhost:8888/
> ProxyPreserveHost On
> RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
>
> It's in there already, and it works great (I even have a couple of CGIs
> reading and building up that table, enabling, disabling and prioritizing
> hosts).
>
> http://wiki.apache.org/cocoon/ApacheModProxy
> http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
>
> Pier
Re: [proxy] New implementation ready for testing
Posted by Jeffrey Burgoyne <bu...@keenuh.com>.
I plan on doing a pretty thourough test as soon as I get access to the box
we will be using. Currently our network specialists are working to get the
front end Alteon load balancers working properly. We've been hampered by a
number of linux network issues that may yet take some time to resolve.
Jeffrey Burgoyne
Chief Technology Architect
KCSI Keenuh Consulting Services Inc
burgoyne@keenuh.com
On Mon, 16 Aug 2004, Graham Leggett wrote:
> Jeffrey Burgoyne wrote:
>
> > The first one is this method as prescribed above does not seem to have a
> > failover mechanism, i.e. if connection to one server fails, then the next
> > in line is tried. This is quite important for mission critical
> > installations.
>
> > The second is that while pure randomness is better than nothing, some
> > weighting system has significant advantages. The first one, from my
> > perspective, is the ability to define a back end primary and secondary
> > service. For example, if I could weight one server at 100 and another at
> > 0, then the primary server would always be called, unless it went down and
> > then the secondary server would be called.
>
> In theory the proxy balancer should do the above for you. Can you give
> the new httpd v2.1 proxy code a test to see if it works?
>
> Regards,
> Graham
> --
>
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Jeffrey Burgoyne wrote:
> The first one is this method as prescribed above does not seem to have a
> failover mechanism, i.e. if connection to one server fails, then the next
> in line is tried. This is quite important for mission critical
> installations.
> The second is that while pure randomness is better than nothing, some
> weighting system has significant advantages. The first one, from my
> perspective, is the ability to define a back end primary and secondary
> service. For example, if I could weight one server at 100 and another at
> 0, then the primary server would always be called, unless it went down and
> then the secondary server would be called.
In theory the proxy balancer should do the above for you. Can you give
the new httpd v2.1 proxy code a test to see if it works?
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Jeffrey Burgoyne <bu...@keenuh.com>.
I've been following the changes to mod_proxy and have been absolutely
estatic as to where everything is headed and what is being done. I've been
working with a very large client for two years changing their whole
architectuer and using an Apache front end employing mod_proxy to their
backend technologies, which is just about everything under the sun.
I have a few comments on the direction this thread is following. Some may
be more to my ignorance as I've only been looking at these threads deeply
for the past two weeks (as the client is finally convinced to move to
apache 2 from the 1.3 series).
The first one is this method as prescribed above does not seem to have a
failover mechanism, i.e. if connection to one server fails, then the next
in line is tried. This is quite important for mission critical
installations.
The second is that while pure randomness is better than nothing, some
weighting system has significant advantages. The first one, from my
perspective, is the ability to define a back end primary and secondary
service. For example, if I could weight one server at 100 and another at
0, then the primary server would always be called, unless it went down and
then the secondary server would be called.
While tying this all in with mod backhand is good as suggested, perhaps
even simpler would be a least connections test. I'm deploying an Alteon
front end to the Apache web server for the client, and wghen investigating
all the options available for load balancing, least connections definitely
won out. In thecase of connecting to a back end app server I can see where
it is not as good, but is relatively simple to implement. I suppose it
would also have to be "least active connections" if the connection pooling
gets done.
Another consideration for the future is handling all of this when you are
running mutliple servers with Apache up front in a load balanced
enviornment. I am currently deploying an IBM blade center which
equivelantly is 14 PC's sharing some common resources, but not memory.
Whether in load balancing or connection pooling it would be nice to have
some level of communication between the blades to ensure the system runs
more smoothly.
Lastly, iI feel if I am going to make some recommendations, I should
contribute something back. While I am not comfortable with the time I have
available to help with coding, I can easily commit to some testing and
verification time as soon as I have my test blade center up.
Cheers, and thanks for the good work everyone.
Jeffrey Burgoyne
Chief Technology Architect
KCSI Keenuh Consulting Services Inc
burgoyne@keenuh.com
On Mon, 16 Aug 2004, Graham Leggett wrote:
> Pier Fumagalli wrote:
>
> > What's wrong with:
> >
> > ProxyPassReverse / http://localhost:8888/
> > ProxyPreserveHost On
> > RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> > RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
>
> It isn't very elegant though. Someone who is well versed in mod_rewrite
> and regular expressions might find it really easy, but the rest of us
> mortals won't. :(
>
> Regards,
> Graham
> --
>
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Pier Fumagalli wrote:
> What's wrong with:
>
> ProxyPassReverse / http://localhost:8888/
> ProxyPreserveHost On
> RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
It isn't very elegant though. Someone who is well versed in mod_rewrite
and regular expressions might find it really easy, but the rest of us
mortals won't. :(
Regards,
Graham
--
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Remy Maucherat <re...@apache.org>.
Pier Fumagalli wrote:
> On 11 Aug 2004, at 17:14, Mladen Turk wrote:
>
>> Hi all,
>>
>> We've finished the initial development of extended mod_proxy.
>> Since the development took place at jakata-tomcat-connectors,
>> the source code can be found under ajp/proxy.
>>
>> Here is the list of major features added:
>> 3. Added new module proxy_balancer
>
>
> What's wrong with:
>
> ProxyPassReverse / http://localhost:8888/
> ProxyPreserveHost On
> RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
>
> It's in there already, and it works great (I even have a couple of
> CGIs reading and building up that table, enabling, disabling and
> prioritizing hosts).
>
> http://wiki.apache.org/cocoon/ApacheModProxy
> http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
http://jakarta.apache.org/tomcat/tomcat-5.0-doc/balancer-howto.html#Using%20Apache%202%20with%20mod_proxy%20and%20mod_rewrite
Performance is very bad (much worse than mod_jk, according to testing),
failover is questionable, and load balancing policies are not available.
So this is definitely a great hack, and it's likely very useful for some
people but it's not generic enough, and definitely isn't a "marketable"
solution.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Theo Schlossnagle wrote:
> I haven't had the time lately, but you (all) are welcome to dissect the
> mod_backhand (Apache 1.3) module and pull the resource collection and
> decision making framework out and put in into mod_proxy for Apache 2.
I have been watching the commits to proxy, but haven't yet had time to
go into them in detail yet, so this may or may not be already possible:
The balancer module should be replaceable, so if you had a java
application server backend the current balancer with session stickiness
would probably work for you. Then in other environments, one of the
mod_backhand components could be switched in to have balancing work
entirely differently.
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Theo Schlossnagle wrote:
> I haven't had the time lately, but you (all) are welcome to dissect the
> mod_backhand (Apache 1.3) module and pull the resource collection and
> decision making framework out and put in into mod_proxy for Apache 2.
I have been watching the commits to proxy, but haven't yet had time to
go into them in detail yet, so this may or may not be already possible:
The balancer module should be replaceable, so if you had a java
application server backend the current balancer with session stickiness
would probably work for you. Then in other environments, one of the
mod_backhand components could be switched in to have balancing work
entirely differently.
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Theo Schlossnagle <je...@omniti.com>.
On Aug 16, 2004, at 6:54 AM, Pier Fumagalli wrote:
> On 11 Aug 2004, at 17:14, Mladen Turk wrote:
>
>> Hi all,
>>
>> We've finished the initial development of extended mod_proxy.
>> Since the development took place at jakata-tomcat-connectors,
>> the source code can be found under ajp/proxy.
>>
>> Here is the list of major features added:
>> 3. Added new module proxy_balancer
>
> What's wrong with:
>
> ProxyPassReverse / http://localhost:8888/
> ProxyPreserveHost On
> RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
>
> It's in there already, and it works great (I even have a couple of
> CGIs reading and building up that table, enabling, disabling and
> prioritizing hosts).
>
> http://wiki.apache.org/cocoon/ApacheModProxy
> http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Having a human weigh or prioritize hosts may work well in a small
environment, but it is too much to manage in a large one. Besides,
while random selection is a decent algorithm under certain
circumstances, mod_proxy lacks the insight into the global state of
resources to make truly intelligent resource-based allocation
decisions.
I haven't had the time lately, but you (all) are welcome to dissect the
mod_backhand (Apache 1.3) module and pull the resource collection and
decision making framework out and put in into mod_proxy for Apache 2.
The algorithms therein are flexible, proven and even extensible. We
have seen several large architectures use m_b with great success in
front of even ISS servers and Java application servers of all types.
http://www.backhand.org/mod_backhand/
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// OmniTI Computer Consulting, Inc. -- http://www.omniti.com/
// Ecelerity: fastest MTA on Earth
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Pier Fumagalli wrote:
> What's wrong with:
>
> ProxyPassReverse / http://localhost:8888/
> ProxyPreserveHost On
> RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
> RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
It isn't very elegant though. Someone who is well versed in mod_rewrite
and regular expressions might find it really easy, but the rest of us
mortals won't. :(
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
> Hi all,
>
> We've finished the initial development of extended mod_proxy.
> Since the development took place at jakata-tomcat-connectors,
> the source code can be found under ajp/proxy.
>
> Here is the list of major features added:
> 3. Added new module proxy_balancer
What's wrong with:
ProxyPassReverse / http://localhost:8888/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
It's in there already, and it works great (I even have a couple of CGIs
reading and building up that table, enabling, disabling and
prioritizing hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Pier
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
Rainer Jung wrote:
> Concerning session stickyness: is the following scenario possible with
> your mod_proxy, at least in the future?e
>
> We support a critical high load application which is running in a two
> cell environment.
>
> We replicate via TC cluster locally inside each cell (2 TCs) but not
> over the boundaries of the cells (cluster would be to big and for a cell
> outage it would be acceptable to loose sessions). So a cell is equal to
> a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute
> A1, A2, B1, B2, where A and B are the cells.
>
> Also we use session stickyness on multiple Apache/mod_jk to keep hopping
> of requests from primary to secondary TCs low. Any apache needs to send
> requests sticky to the correct TC instance. Both TC clusters provide the
> same webapps.
>
> Now, if TC A1 is going down for maintenance (or breaks), and apache
> receives a request with jvmRoute A1, it should send the request to
> another member of the same cluster, in this case A2 and not to B1 or B2.
> Could this be done with mod_proxy?
>
> I did some project patches for mod_jk to make this happen (adding an
> attribute "domain" to the balanced_workers and enhancing
> get_most_suitable_worker in the lb worker.
>
Think that the routeRedirect should be sufficient enough.
If the particular node is marked *disabled* then the requests
will be redirected to that node. So you will have to manually
edit your 'domains', meaning:
Node A1 -> routeRedirect A2, etc...
This scenario is already supported inside proxy_balancer and jk2.
MT.
Re: [proxy] New implementation ready for testing
Posted by Rainer Jung <to...@kippdata.de>.
Concerning session stickyness: is the following scenario possible with
your mod_proxy, at least in the future?
We support a critical high load application which is running in a two
cell environment.
We replicate via TC cluster locally inside each cell (2 TCs) but not
over the boundaries of the cells (cluster would be to big and for a cell
outage it would be acceptable to loose sessions). So a cell is equal to
a replication domain resp. to a TC cluster. Let's say TCs with jvmRoute
A1, A2, B1, B2, where A and B are the cells.
Also we use session stickyness on multiple Apache/mod_jk to keep hopping
of requests from primary to secondary TCs low. Any apache needs to send
requests sticky to the correct TC instance. Both TC clusters provide the
same webapps.
Now, if TC A1 is going down for maintenance (or breaks), and apache
receives a request with jvmRoute A1, it should send the request to
another member of the same cluster, in this case A2 and not to B1 or B2.
Could this be done with mod_proxy?
I did some project patches for mod_jk to make this happen (adding an
attribute "domain" to the balanced_workers and enhancing
get_most_suitable_worker in the lb worker.
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Mladen Turk <mt...@apache.org>.
Remy Maucherat wrote:
>
> So compared to AJP, this gives what ?
Nothing regarding performance :)
Or you can use the https to connect to
the tomcat on the internet.
> Q: is there session stickiness in HTTP ?
>
Yes.
> Congratulations for improving on mod_jk performance :)
>
>>
>> proxy_balancer:
>
> Does it do session stickiness right now ?
>
Yes, and redirect_route too.
In addition it has options missing from jk.
The sticky session param/cookie is configurable.
You have a force-sticky option (if there is no backend session replication).
MT.
Re: [proxy] New implementation ready for testing
Posted by Graham Leggett <mi...@sharp.fm>.
Remy Maucherat wrote:
> Q: is there session stickiness in HTTP ?
As I understood from the commits, stickiness is part of balancer, and
balancer is protocol independant, which would make the answer yes.
Am I understanding correctly?
Regards,
Graham
--
Re: [proxy] New implementation ready for testing
Posted by Remy Maucherat <re...@apache.org>.
Mladen Turk wrote:
> Hi all,
>
> We've finished the initial development of extended mod_proxy.
> Since the development took place at jakata-tomcat-connectors,
> the source code can be found under ajp/proxy.
>
> Here is the list of major features added:
> 1. AJP13 protocol support
> 2. Connection pool for threaded servers
> 3. Added new module proxy_balancer
> 4. Added mod_status extended information hook.
>
> Connection pool:
>
> The connection pool enables reusing backend connections
> and was build around apr_reslist. At the moment only the
> proxy_ajp extensively uses this connection pool, with
> performance slightly better then mod_jk.
> Http module also uses connection pool, but only to the
> level of skipping DNS lookup, and shows around 20% performance
> boost over the current implementation.
> Ftp module although uses the connection pool will need more
> testing.
So compared to AJP, this gives what ?
Q: is there session stickiness in HTTP ?
Congratulations for improving on mod_jk performance :)
>
> proxy_balancer:
>
> The new proxy balancer is capable to balance the load trough
> the cluster of backend server. For the moment the implemented
> algorithm is based on the preset dispatch factor, counting
> the number of connections processed on each node.
> It can mix the protocols so one can make a cluster containing
> the http, ajp and ftp backends, although the usability of such
> configuration is questionable.
Does it do session stickiness right now ?
>
> TODO:
>
> 1. Testing
> 2. Bugfixing
> 3. finish AJP13 (ssl + resend)
>
>
> P.S.
> I'll be on vacation for the next two weeks, and unreachable by
> the standard electronic devices.
Rémy
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:14 AM 8/11/2004, Mladen Turk wrote:
>The connection pool enables reusing backend connections
>and was build around apr_reslist. At the moment only the
>proxy_ajp extensively uses this connection pool, with
>performance slightly better then mod_jk.
I noticed one huge win - unless I'm misreading... we don't require
any includes from j2sdk/include/ ??? That in and of itself is great :)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
At 11:14 AM 8/11/2004, Mladen Turk wrote:
>We've finished the initial development of extended mod_proxy.
>Since the development took place at jakata-tomcat-connectors,
>the source code can be found under ajp/proxy.
That's something of a shame, because we lose the development
history importing the finished effort, and it was further disappointing
that you didn't bring across the earlier cvs history so this branch
could be brought back into httpd/modules/proxy with a complete
history.
I'm actually very excited that we can offer in the 2.2 release - this
really rocks. What you accomplished is very cool!
I'm entirely +1 today for bringing it back into modules/proxy/ (it's
a c-t-r branch.) How you did it makes this a non-trivial exercise.
Boo :(
(Sorry my earlier responses only seem to have hit httpd-dev, due to
trashcan'ned moderation and my list-receipt email differing from my
-accept from account differing.)
Bill
---------------------------------------------------------------------
To unsubscribe, e-mail: tomcat-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tomcat-dev-help@jakarta.apache.org
Re: [proxy] New implementation ready for testing
Posted by Pier Fumagalli <pi...@betaversion.org>.
On 11 Aug 2004, at 17:14, Mladen Turk wrote:
> Hi all,
>
> We've finished the initial development of extended mod_proxy.
> Since the development took place at jakata-tomcat-connectors,
> the source code can be found under ajp/proxy.
>
> Here is the list of major features added:
> 3. Added new module proxy_balancer
What's wrong with:
ProxyPassReverse / http://localhost:8888/
ProxyPreserveHost On
RewriteMap hosts rnd:/opt/apache/conf/tables/hosts.map
RewriteRule "^/(.*)" "${hosts:live}/$1" [P,L]
It's in there already, and it works great (I even have a couple of CGIs
reading and building up that table, enabling, disabling and
prioritizing hosts).
http://wiki.apache.org/cocoon/ApacheModProxy
http://wiki.apache.org/cocoon/LoadBalancingWithModProxy
Pier