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 |
thanks philippe for this good energy.
Stef On Apr 9, 2012, at 11:48 AM, 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 > > |
In reply to this post by Philippe Marschall-2-3
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 I like the WADwBenchHandler because it does dynamically create a 25x25 table on each request. 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 ? Sven -- Sven Van Caekenberghe http://stfx.eu Smalltalk is the Red Pill smime.p7s (5K) Download Attachment |
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 |
Free forum by Nabble | Edit this page |