Some more optimizations...
Le 4/27/12 5:37 PM, Emmanuel Lécharny a écrit :
Today, I did some profiling with the latest version of Yourkit, and I
was able to tweak the server here and there to get some speed
improvement. Here are the results I get :
on Trunk :
OBJECT level search, 19 680 entries returned per second (we only get
one entry)
ONE level search, 27 900 entries returned per second (we get five
entries)
SUBTREE level search, 17870 entries returned per second (we get 10
entries)
Keep in mind that those tests are done with an embedded server, it
does not go through any network layer. So to speak, it gives the raw
caacity of the server to deliver entries, no more.
On the branch now :
OBJECT level search, 33 373 entries returned per second (we only get
one entry) : this is a 70% improvement !
ONE level search, 45 695 entries returned per second (we get five
entries): this is a 63% improvement !
SUBTREE level search, 35 300 entries returned per second (we get 10
entries): this is a 97% improvement !!!
I'm quite confident that we can still improve the performances of the
server, I have just scratched the surface here :)
Latest numbers, after some more cleanup and improvement :
OBJECT level search, 35 253 entries returned per second (we only get one
entry) : this is a 73% improvement
ONE level search, 63 855 entries returned per second (we get five
entries): this is a 123% improvement
SUBTREE level search, 68 560 entries returned per second (we get 10
entries): this is a 181% improvement
I have also measured the server-integ tests (so through the network).
The results are less impressive.
Trunk Server-integ tests :
OBJECT level search, 2 726 entries returned per second (we only get one
entry)
ONE level search, 4 999 entries returned per second (we get five entries)
SUBTREE level search, 2 425 entries returned per second (we get 10 entries)
Branch Server-integ tests :
OBJECT level search, 2 739 entries returned per second (we only get one
entry) : barely the same
ONE level search, 5 229 entries returned per second (we get five
entries) : this is a 4,6% improvement
SUBTREE level search, 3 079 entries returned per second (we get 10
entries) : this is a 27% improvement
One might wonder why we get such numbers when the core-integ tests are
way higher. The reason is that we have to encode and decode the entries,
and the very same for the SerahcRequest itself. This is an extreely
costly operation on the client side : barely one third is consummed by
the client decoding the entries. Would we have the injector on another
machine, we would have way better numbers.
The result encoding is also a costly operation, but there is little we
can do here (except may be keep the encoded Entry somewhere in a cache,
bt I' not sure that would be very efficient). Also as the server is
waiting for the client to have processed the entries, we really depend
on the client, and it's hard to get the server beng loaded with such a
scenario.
I'm done for today, I'll check if I can squeeze more perfs tomorrow.
nn guys !
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
