Beefy Boxes and Bandwidth Generously Provided by pair Networks
good chemistry is complicated,
and a little bit messy -LW

Re: Designing an enqueing application proxy

by polettix (Vicar)
on Jan 04, 2008 at 00:12 UTC ( [id://660345]=note: print w/replies, xml ) Need Help??

in reply to Designing an enqueing application proxy

I don't understand where the problem is exactly, there are at least two scenarios that come to mind. Both stem from:
WS can't handle more than 10 connections per second, and apparently this limit can't be easily changed.
Do you mean that your experiments show that it's physically impossible (more or less) to get more than 10 connections per second, or that if you try to do more Bad Things™ happen?

In the first case, I'd say that the real problem is that when burst arrive, some requests get discarded and this is the problem. This could probably be addressed tweaking the server's configuration, trying to have longer listen queue sizes, more childs to serve requests, etc. This seems to be indicated also by the fact that you're talking about associating 5 listeners per connector (in this case I'd use one listener with a longer queue, e.g. see the Listen parameter in IO::Socket::INET).

On the other hand, if Bad Things™ happen beyond the 10 req/s limit, then you have to put some throttling mechanism in place. But I'd ask: can we assume that it would be safe if no more than 10 contemporary WS transactions are alive at the same time? Probably yes if the service time is more than 1/10th of second, probably not if the service time is less than this. In any case, I'd try to find how many outstanding requests are good for your case, and start from this: you're eliminating the time variable.

Regarding the implementation, I'd go with IO::Select and avoid all the thread stuff, but it's just me. In this case, you end up with one listener (whose listen queue is sufficiently long according to your needs in terms of rejection probability) and up to 10 * 2 contemporary "working sockes" (one pair for each connection, one towards the WS, the other towards the client). IO::Select over 21 file descriptor shouldn't be an issue.

Hey! Up to Dec 16, 2007 I was named frodo72, take note of the change! Flavio
perl -ple'$_=reverse' <<<ti.xittelop@oivalf

Io ho capito... ma tu che hai detto?

Replies are listed 'Best First'.
Re^2: Designing an enqueing application proxy
by bronto (Priest) on Jan 04, 2008 at 09:13 UTC
    Do you mean that your experiments show that it's physically impossible (more or less) to get more than 10 connections per second, or that if you try to do more Bad Things™ happen?

    The second one: if you try to do more Bad Things™ happen.

    WS is a web service developed on top of a vendor product by the vendor itself. What happens is that if more than 10conn/sec come in, the first 10 are managed, and the exceeding are just accepted and then hung there until they timeout. Vendor says they can't change it, and by the way 10conn/sec are 600conn/min and that's a lot. I am SAYING not saying I agree or disagree here, just reporting it as they told me.

    That's why the final solution was to cortocircuit-ate the developers of PE with those of WS and let them talk. Nevertheless, the problem was so interesting to me that I came out with this design. And having very little experience with threads I wanted to know if the design was ok. And I am also interested in different approaches, like yours for example.

    By the way: thanks to all that answered. I am really curious on how this could be efficiently managed with POE (thanks emazep for talking about that).

    Update: how could my keyboard give birth to the monster error up there????? I am pretty sure I wrote "not saying" from the beginning...


    In theory, there is no difference between theory and practice. In practice, there is.

Log In?

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

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (2)
As of 2024-06-20 05:00 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.