On Sunday, July 20, 2014 4:04:02 PM UTC+5:30, Saúl Ibarra Corretgé wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 07/20/2014 08:35 AM, Ashish wrote: > > > > *Problem:* To make the server faster performing if we do not slow > > down on uv_write, but if receiver is slow in reading responses, we > > are very likely to get UV__ENOBUFS. > > > > Two possible approaches here: > > > > *1. Monitor write_queue_size*: One option is to slow down on > > uv_write by monitoring queued bytes stream->write_queue_size > > However, as Saúl mentioned in this thread: > > https://groups.google.com/forum/#!topic/libuv/34GI5ip_b08 we needs > > to do benchmarking of server to decide on how much maximum value of > > write_queue_size to be allowed to achieve optimum performance. > > (Btw, I read OS maintains 16K buffer for each socket. So can we go > > by that? I mean not letting write_queue_size to grow more than > > 16K?) > > > > > > *2. Set SO_SNDBUF socket option to zero: * As an alternative, as > > per Microsoft's documentation > > (http://support.microsoft.com/kb/201213), if we set the SO_SNDBUF > > socket option to 0 (zero) it allows the stack to send from > > application buffer directly. > > > > i.e.: DWORD NewBuffSize = 0; setsockopt(Socket, SOL_SOCKET, > > SO_SNDBUF, (const char *)&NewBuffSize, sizeof(DWORD)); > > > > This shouldn't need to slow down on uv_write (as there won't be > > internal buffers maintained anymore) > > > > However, I tried this and it doesn't work (And I still get > > UV__ENOBUFS) Any idea why would it not work? > > > > IMHO you are approaching this problem the wrong way. If the recipient > cannot read the data at the pace you are sending it I don't see the > performance gain in trying to write it regardless. Someone will have > to buffer it, be that the application, kernel or what have you, but > chances are those buffers may eventually become full. The recipient > will see no difference if you have 1MB or 1TB of buffered data. > > As I mentioned in some other email, look into handling backpressure by > having some high and low watermarks in you application (per stream). > Stop writing when you reach the high watermark of queued data and > resume when you go lower the low watermark. The queue will always have > some data to send, so you won't have a moment when you paused the > application completely, if you did the above right. > > > Cheers, > > - -- > Saúl Ibarra Corretgé > bettercallsaghul.com > >
I fully agree and respect what you have suggested in another email. In fact I am employing same solution in my server. But the problem with benchmarking is that, it becomes specific to certain type of server. For example, benchmarking I used for text-chat server may not hold valid for video streaming server, as the loads are different (and so upper and lower watermarks will be different for them) I was trying to find wheather is it possible to have a generic solution which is efficient for any type of load. So without knowing load and latencies, same server can be used for any purpose, just on another hardware. (Or are my expectations unrealistic...? ) cheers! -- You received this message because you are subscribed to the Google Groups "libuv" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/libuv. For more options, visit https://groups.google.com/d/optout.
