Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Re: Slow performance of non-blocking select?

by flexvault (Parson)
on Nov 05, 2012 at 16:31 UTC ( #1002355=note: print w/ replies, xml ) Need Help??


in reply to Slow performance of non-blocking select?

Welcome PMCarl,

You don't mention what operating system you're using, but a few things differ greatly with the operating systems I have testing with.

When using 'can_read', I pass 3.025 seconds as:

my @ready = $select->can_read(3.025);
Your comments in your code says it waits the full time so you use 'sleep' with a small time-out. If the above did that, then I would only be able to process 19 transactions per minute. If fact on different *nix systems I process between 8,000 and 38,000 transactions per second per core. So it may be a problem with your platform. Why '3.025' because I started with '.025' and found that using a larger number got better performance than using a smaller number. So I put a '3' in and got better performance. Could be platform related. YMMV.

You mention a 'default' of 64K. I have systems with different read/write buffered ranging from 8K to 512K. You should use 'getsockopt' to find your limits, and then I've found that the best performance is to ask the client for their sizes, and return a 'good' value to the client for all communication. Keep in mind that you can use a hash to keep track of the different 'MAXRD/MAXWR' for each client.

I haven't looked at all of your code, but these items jumped out at me, and since you're trying to improve and generalize the code, maybe this will help.

Update:I changed '19 transactions per second' to '19 transactions per minute' which would be correct ( 60 seconds / 3.025 seconds ).

Good Luck!

"Well done is better than well said." - Benjamin Franklin


Comment on Re: Slow performance of non-blocking select?
Download Code
Re^2: Slow performance of non-blocking select?
by PMCarl (Initiate) on Nov 05, 2012 at 22:09 UTC
    Thanks flexvault!

    My first thought was: "I'm using non-blocking IO::Select objects, so the time-out shouldn't matter"

    ...but that seems to have been the problem. 'can_read' and IO::Select::select both seem to be blocking even though I'm calling $obj->blocking(0);

    By using a very small time-out, I'm able to get very close to the performance of the original version of that package. Some runs actually show the new version out-performing the old one.

    The way the code is structured, it misses time that it could be doing other things while it is being blocked on can_read, so I don't get the advantage that you may be getting.

    Cheers!

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1002355]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (10)
As of 2014-09-19 07:53 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (133 votes), past polls