-----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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/ iQIcBAEBAgAGBQJTy5quAAoJEEEOVVOum8BZecsP/jTHUPg/GVEtOKVUZYCVbU3d PTXt/BzTEJ5OCxeAiHhV5yDQfF1HPvMTUnDvzkq2/IgyodEC2N1GGOwdoEnCKSVZ 1Z9TYIVNC/GNakpyaFbKE+je+LPmgthREbqJDf7anDiGgdqL1gPOnI74oHDhW0Dy QvE10v2dt9q9rJ7Cmiw53PyqEyM3Yk0ZcWMqz7R3CGRmaX8+R9hMcePAvY8ne9GJ ZmEOrLHBCy46STxZemZvSBGllULHeIujIkAAqo0mloqxxBKnmdNuumBKmHiYRD0N svGf5XBslF8ArHiEUKt2OnG1V8SLkPpq4/hl/OWzVzja133NzZkSMezVG/CnBmLv n1rhN8hwd2TnBsyAFpR3GaCO/TWH4gclLiWEVpWtUsAazKSyWy0ebpYqsSqvvZVz vZ0MTE+Urete6U2DwRhoVqr4J7C5T/avbkYw3ndAGpGjVk+bN0pqC5y/liB0HFG8 OuE6NbrfdMYZOHGfUd/3NSCocvpgl/X8gAJX8agS/9CLT3sF2XBN2LyXh4mGUerZ Z94xstTGZzsHDTXcv7Knj0qpiM7bBkdIiAN0CabTOuat4NIYVa65yTKkGxjgG7UY lp1GuIAfUHon7ZdyItoOKnBg1VNv1SpAWus7LzC4jzkVL92bZhkRYmGG/18ADChB hBoByaEJECCJb28wuT5I =SRFP -----END PGP SIGNATURE----- -- 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.
