I don't know. I thought about it before but believe it will create some design complexity in my application.
As currently I maybe able to re-implement some kind of polling mechanism from the ground level, I don't think I'll play that large'n'small buffer game. + It's always fun to play with the lower level system call. But who knows, I may come back to it when I'm in despair. On Monday, March 6, 2017 at 8:27:05 PM UTC+8, Jakob Borg wrote: > > If most of your connections are idle most of the time, and your memory > usage comes from something like > > buf := make([]byte, 65536) > n, err := conn.Read(buf) // <-- block here for ever > > you could simply use a smaller buffer for the read that takes a long time. > For example, if the message is length prefixed, just read into a [4]byte or > similar and *then* grab a buffer from a sync.Pool or create one when you > know the size to read. Even if the message is not length prefixed but you > know it's long, you can still read the first few bytes into a small buffer > and then read the rest once that call returns, appending to the first read. > This won't be efficient in a tight loop, but if you know a point where may > clients idle it may be worth it. > > //jb > > > On 6 Mar 2017, at 09:26, Nick Rio <nick...@gmail.com <javascript:>> > wrote: > > > > The application is working right now. Current work for me is to found a > way to reduce it's memory footprint as it will take at least 1GB memory to > hold only C10K idle connections. > > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
