<div class="gmail_quote">On 8 November 2011 06:08, Anton Lebedevich <span dir="ltr"><<a href="mailto:mabrek@gmail.com">mabrek@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 11/02/2011 07:21 AM, Tim Watson wrote:<br>
> I've found the gen_servers that use cast heavily can easily get<br>
> overwhelmed without back pressure.<br>
<br>
</div>I'm considering providing both kinds of API: call and cast.<br>
What's the better way to implement back pressure?<br>
Currently there are 3 queues: driver process inbox, driver internal<br>
queue of sent to backend requests, tcp send buffer.<br>
One kind of backpressure implementation might look like using<br>
gen_server:call that returns after calling gen_tcp:send. In this case<br>
slow database will eventually stop reading from tcp socket, then<br>
gen_tcp:send will hang, then gen_server:call will hang too.<br>
<div class="im"><br></div></blockquote><div><br></div><div>Take a look at <a href="https://github.com/esl/jobs">https://github.com/esl/jobs</a>. Whilst you might not wish to depend on it directly, it implements a pretty good model for wiring sensors that can be used to regulate queue sizes. There are other solutions around too, like pooling and so on. I think your idea of using the responsiveness of the network might work quite well, although it's just gut feeling there and I'm sure others on the list will have more practical experience to share.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> Now honestly, you're really missing a trick with this change. Does the<br>
> client (pid) get a message as soon as data comes off the wire and a row<br>
> has been successfully decoded? Because that is *far* more useful that<br>
> just happening not to block the client pid while you go off and fetch<br>
> everything in one go. If you either allow the client to pass a callback<br>
> or simply send a message for each DataRow, you will have provided a boon<br>
> for fast web applications.<br>
<br>
</div>I've started experimenting with it in branch<br>
<a href="https://github.com/mabrek/epgsql/tree/row-callback" target="_blank">https://github.com/mabrek/epgsql/tree/row-callback</a><br>
Currently it's incomplete, passes only one test case.<br>
<br></blockquote><div><br></div><div>Cool! I shall have a good play with this. Are you planning on benchmarking your driver once it's more complete? IIRC the Tsung load testing tool supports postgres and I wonder if perhaps one could tweak that to benchmark the various postgres drivers based on a few stereotypical use cases?</div>
</div>