Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re: Slow performance of non-blocking select?

by flexvault (Prior)
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
Replies are listed 'Best First'.
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.


Log In?

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

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (14)
As of 2015-11-25 15:40 GMT
Find Nodes?
    Voting Booth?

    What would be the most significant thing to happen if a rope (or wire) tied the Earth and the Moon together?

    Results (681 votes), past polls