Re: [go-nuts] 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?

[Leonardo Santagada]

First step in fixing memory problems is measuring it. A goroutine IIRC 
reserves 2kb of stack space only, so removing goroutines from your program 
and probably rewriting everything keeping all else the same will save you 
100*2kb memory. Seems like a lot of work for little to no gain. Do present 
a memory profile of your program and lets see what is the culprit/culprits 
of this memory usage.

On Monday, March 6, 2017 at 1:42:54 PM UTC+1, Nick Rio wrote:
>
> 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  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.

Re: [go-nuts] 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?

[Nick Rio]

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  
> 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.

Re: [go-nuts] 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?

[Jakob Borg]

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  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.

[go-nuts] 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?

[Tamás Gulácsi]

Are you sure that those goroutines will consume too much memory?
As the Go runtime implements a very sophisticated network stack on top of 
epoll, I wouldn't start from scratch, but use it, eliminating unneeded 
allocations (buffers).

-- 
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.

[go-nuts] 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?

[nickriose]

Greeting people,

*TL;DR: The only option is to work with syscall package and build 
everything ground up, or there are some easier way?*

The story is, I'm working on a network related project 
(https://github.com/nickrio/coward) which been designed to take a lots of 
connections. Most of those connections is just idle, but hey can back to 
active at any time.

Currently, that application is implemented in Go's style -- When a new 
connection is accepted, a new goroutine is created, along with associated 
buffer and structs.

The downside of that is, I have to create a buffer for each goroutine (for 
each connection), no matter that connection is active or not. And because 
of that, there will be a lots of memory space been wasted (goroutine also 
cost few KB of memories).

So I'm thinking, if I can somehow re-implement connection handling in 
epoll-like model, then I could save those idle memory for better memory 
efficiency.

After dug few pages of source code on golang.org, I discover that in order 
to do so, I have to work with some *low* level system calls (the package 
name is literally syscall) and runtime package.

So before I get started, I want to do the last check to make sure there are 
no any other way to go (No built-in package or x package will help me to do 
that. Sorry, I'm new to Golang, if there are a magic hidden inside, I 
probably wouldn't found it. So better ask to make sure), so I don't waste 
my time doing it.

Thank you!

(Sorry for my English)

-- 
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.