On 09.04.2012 18:44, Sven Van Caekenberghe wrote:
On 09 Apr 2012, at 11:48, Philippe Marschall wrote:
Hi
This is a small update on the work I've been doing on the AJP adapter for
Seaside. I've optimized the content rendering and reduced the amount of copying
it does for content rendering (header rendering still does more copying than
strictly necessary).
The most dramatic change is with a 16k response (WAFastRequestHandler) where
throughput is up from 75 Mbytes/s to 100 Mbytes/s [1]. This is now close to
saturating a gigabit link. With an 8k response (WADwBenchHandler) we're now at
about 7500 req/s [2] up from a about 6500 req/s. That's close to where the 2
byte response performance was back in February. Speaking of which a 2 byte
response (WASmallRequestHandler) is now at 8700 req/s [3] up from about 8100
req/s.
Apache 2.2.22 mpm_worker mod_proxy_ajp
CPU Intel(R) Core(TM)2 Duo CPU E7500 @ 2.93GHz
Cog r2540
You can get the code in the Seaside-Benchmark package in the addons repository
[4].
[1] https://gist.github.com/2339951
[2] https://gist.github.com/2339947
[3] https://gist.github.com/2339940
[4] http://www.squeaksource.com/Seaside31Addons
Cheers
Philippe
That is great news, Philippe.
I like the WADwBenchHandler because it does dynamically create a 25x25 table on
each request.
No, I modified it so that it just returns a "static" byte array. I
didn't want to benchmark any other code.
Proves that you can get far by optimizing really hard.
Another datapoint for those asking performance related questions.
Are the rendering optimizations that you did something that will be/become part
of Seaside proper ?
Yes and no. The parts where Seaside code was involved are in the latest
3.1 code. The rest is a custom subclass of WARequest that only works for
AJP. Moving this to Seaside would make no sense. The trick here is to
use a custom stream-like object that gets reused for every request and
to which I don't have to send #contents (because that makes a copy).
It's tricky because AJP uses 8k packets and I have to insert a header
and trailer at the packet boundaries. It would be simpler to do for HTTP
because you don't need to deal with packet boundaries. But tight
integration with the server is required.
Cheers
Philippe
