*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? Tnx, Ashish -- 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.
