Mladen Turk wrote:
Yes, that's the general idea. We focus on v2.0 and TCP/IP protocol (for now).
Cool.
Well, the development will not be over in 2 days, and the plan is to use mod_ajp as a base for testing new protocol extensions, and to be always a little bit faster and better then mod_proxy with proxy_ajp :).
Don't forget mod_proxy is just a framework - there would be no "faster than proxy_ajp" because prioxy_ajp would be mod_ajp with config directives arranged differently.
Remember that the benchmarks that were done recently compared mod_ajp with mod_proxy_http, not mod_proxy. As is clear from the benchmarks, mod_proxy_http could benefit greatly from a connection cache for a start. If that connection cache were protocol neutral, then mod_proxy_ftp could benefit from the connection pool too.
The mod_proxy itself will have to face a lot of extra work too.
Exactly - which is why I'm dead keen to have the AJP work aligned with proxy, so that proxy can benefit from AJP features like load balancing, etc.
It will at least have to have a maintainable set of connection pools for each backend server, so one can implement a load balancer from them, and also control the number of connections the backend can handle. mod_core will need an extra work too, so that the scoreboard can be extended to store the lb params. This is essential if one wishes to have a load balancer.
If you succeed to build such a feature for mod_proxy and http protocol, then
we will already have a ready proxy_ajp protocol extension.
From the sounds of things, many of these features exist (or will soon exist) in mod_ajp. Moving or copying these features out of mod_ajp and into either mod_proxy* or any of the core modules isn't a difficult thing to do. If you create patches that you need for either proxy or the core to support stuff that you need, I'll make sure they get into httpd v2.1 with support for inclusion into httpd v2.0.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
