I also used NYTProf to see where time was spent. Of course ( removing
the waiting time ) the main time is spent in external module such as
Danga::Service or IO::Handle.
But I noticed something quite interesting, many time is lost in the
Hash::Util::lock_ref_keys sub. This function is used by fields::new
since perl 5.009.
I think that using fields is a really good technique during
development stage, and code should not be changed. But once we would
like to set the server as a production one, it can be a good idea to
disable this part.
So I've worked on a ( very ) simple patch that could allow any user to
disable field::new usage by setting PERLBAL_REMOVE_FIELDS to 1 as an
env var. ( In this case only field::new is mocked ).
What do you think about this idea ?
Benchmark I've done so far show that this simple patch can improve
performance by 30 %.
You could access to the patch there : https://rt.cpan.org/Public/Bug/Display.html?id=72671
I used ApacheBench ( known as ab ) to generate 100,000 requests on a
perlbal reverse proxy set with 2 nodes ( from a distinct server )
I launched 5 times ab generating 100,000 requests with concurrency =
100 ( ~ 140 sec / test ). I do not restart server between two tests,
this explain why number is decreasing from one test to another one.
> ab -n 100000 -c 100 http://127.0.0.1/
Here are the results of my bench :
## remove_fields = 0
1 - 765.09 req/sec
2 - 726.90 req/sec
3 - 718.17 req/sec
4 - 711.89 req/sec
5 - 706.41 req/sec
average = 725 req / sec
## remove_fields = 1 [ PERLBAL_REMOVE_FIELDS=1 ]
1 - 988.02 req/sec
2 - 948.28 req/sec
3 - 930.01 req/sec
4 - 921.05 req/sec
5 - 917.66 req/sec
average = 941 req / sec
=> Delta = + 29.6 %
Any comment will be appreciate
thanks for reading
___________________________________
Nicolas Rochelemagne
"bad result"?
> I also used NYTProf to see where time was spent. Of course ( removing
> the waiting time ) the main time is spent in external module such as
> Danga::Service or IO::Handle.
> But I noticed something quite interesting, many time is lost in the
> Hash::Util::lock_ref_keys sub. This function is used by fields::new
> since perl 5.009.
Neat!
> I think that using fields is a really good technique during
> development stage, and code should not be changed. But once we would
> like to set the server as a production one, it can be a good idea to
> disable this part.
> So I've worked on a ( very ) simple patch that could allow any user to
> disable field::new usage by setting PERLBAL_REMOVE_FIELDS to 1 as an
> env var. ( In this case only field::new is mocked ).
> What do you think about this idea ?
I have no idea! I'd need to look at it more closely. Anyone else on the
list understand this better than I do?
> Benchmark I've done so far show that this simple patch can improve
> performance by 30 %.
> You could access to the patch there : https://rt.cpan.org/Public/Bug/Display.html?id=72671
I do have some patch feedback though:
- You did a lot of fiddling with MANIFEST/etc. Can you split all of that
into a distinct patch with some commentary on why you made those changes?
- Can you clean up the style of the new .pm files to match the rest of the
project a bit more? Headers, spacing, etc. I'm trying to add less code
with distinct style code :P
> I used ApacheBench ( known as ab ) to generate 100,000 requests on a
> perlbal reverse proxy set with 2 nodes ( from a distinct server )
> I launched 5 times ab generating 100,000 requests with concurrency =
> 100 ( ~ 140 sec / test ). I do not restart server between two tests,
> this explain why number is decreasing from one test to another one.
> > ab -n 100000 -c 100 http://127.0.0.1/
>
> Here are the results of my bench :
>
> ## remove_fields = 0
> 1 - 765.09 req/sec
> 2 - 726.90 req/sec
> 3 - 718.17 req/sec
> 4 - 711.89 req/sec
> 5 - 706.41 req/sec
>
> average = 725 req / sec
>
> ## remove_fields = 1 [ PERLBAL_REMOVE_FIELDS=1 ]
> 1 - 988.02 req/sec
> 2 - 948.28 req/sec
> 3 - 930.01 req/sec
> 4 - 921.05 req/sec
> 5 - 917.66 req/sec
>
> average = 941 req / sec
>
> => Delta = + 29.6 %
Excellent! 30% isn't too shabby for a first shot. Curious though; were you
running these tests with XS::HTTPHeaders enabled? If not, could you re-run
the tests with it enabled? The performance improvement may be even higher.