Well, 1 GB memory is certainly too many as they are mostly idle. They *should* cause as little as zero when in idle, right?
I really hope they can add that (IO Notify Poll?) into Golang so I can implement my server in other models instead of One-Connection-One-Goroutine one. On Monday, March 6, 2017 at 6:58:50 PM UTC+8, John Souvestre wrote: > > Ni Nick. > > > > Is 1GB too much? What is your target for number of connections and max > memory size? > > > > You are using about 100KB per connection? Is there any way to reduce > this? The goroutine certainly isn’t much of that. Perhaps some way of > using a smaller buffer while idling? > > > > Go does use epoll, but not sharing the memory. It sounds like it might be > a nice option for the future, however. > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com <javascript:> [mailto: > golan...@googlegroups.com <javascript:>] *On Behalf Of *Nick Rio > *Sent:* 2017 March 06, Mon 02:26 > *To:* golang-nuts > *Subject:* Re: [go-nuts] Re: How can I implement a TCP server using a > model which similar to epoll (or kqueue, IOCP) rather than just using > goroutine for each client? > > > > Hi John, > > 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. > > I know it's mainly me causing such memory usage, so I just want to know if > there are a better way to get around my problem without changing too many > of those already existing design. That's is when the epoll-style idea came > out. > > + epoll-styled design is seems suits better for my application by nature. > > I really hope Golang can have it built in though. > > On Monday, March 6, 2017 at 3:54:19 PM UTC+8, John Souvestre wrote: > > What you propose sounds like a lot of extra work at the onset. Consider > starting with a simple trial version of your program would get you up and > running with less effort. This way you could see whether CPU or memory is > the limiting factor, and could work to optimize just that factor (and not > waste time on the wrong factor). Or perhaps the trial version will achieve > your goals without having to do any optimization. J > > > > John > > John Souvestre - New Orleans LA > > > > *From:* golan...@googlegroups.com [mailto:golan...@googlegroups.com] *On > Behalf Of *Nick Rio > *Sent:* 2017 March 05, Sun 23:28 > *To:* golang-nuts > *Subject:* [go-nuts] Re: How can I implement a TCP server using a model > which similar to epoll (or kqueue, IOCP) rather than just using goroutine > for each client? > > > > Thank you for reply. > > No guys, it's me using too many memories, not Goroutine. > > However, I believe if I can make those code in epoll-style, I can then > build a task queue to handle those connections one by one in a queue when > they back to active. For example, start one *accepter* goroutine + few > *worker* goroutines. > > Then I could do buffer sharing within each *worker* instead of each > connections. Which well reduce a huge bunch of memory requirement + also > reduce numbers of goroutine. > > -- > 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...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > > -- > 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...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/d/optout. > -- 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.
