golang versus C and epoll()

[golangmike]

I have been tasked with writing a server in C and epoll().  I am considering proposing using golang instead.

This server will maintain ten of thousands of connections, so scalability is important.

For purposes of helping me decide if golang is a good replacement for C and epoll(), here is what I am doing:

---

It is essentially a telnet server where the user connects once, logs in (using our own scheme), then is allowed to select another system.  After that all traffic just passes to the target system.

---

That is not exactly what we are doing, so please do not clutter this post with critiques of why that is crazy.

[Ian Lance Taylor]

I'm not sure what you are asking. If you are asking whether it would
be reasonable to write this kind of program in Go, the answer is yes.
This kind of thing is a common use of Go.

For example, see http://talks.golang.org/2013/oscon-dl.slide#1 .

Ian

[golangmike]

Thank you for the slides Ian.

Let me clarify my questions:

1) Will golang have equivalent resource usage as the equivalent program written in C/epoll()?

   a) memory

   b) cpu

   c) added delay to communication

   d) maximum number of connections

2) Is one easier to write and why?

golang seems to handle the multiple connections by using light weight threads.  That seems heavier than epoll(), so any answer that says their are equivalent, I would appreciate and explanation of why threads don't cause a problem.

From my reading, it seems golang seems particularly suitable for this, but I would like an experience golang dev confirm that.

[Ian Lance Taylor]

On Sat, Aug 8, 2015 at 7:22 PM, golangmike <pot...@gmail.com> wrote:
>
> Let me clarify my questions:
> 1) Will golang have equivalent resource usage as the equivalent program
> written in C/epoll()?
> a) memory
> b) cpu
> c) added delay to communication
> d) maximum number of connections

I would expect well written C and Go programs to be roughly equivalent
for this sort of program. While C can be compiled to run slightly
faster than Go, that makes no real difference for a program like this
that is dominated by network usage.

> 2) Is one easier to write and why?

Well, I think the Go program is easier to write, but I expect you
would get a different answer on a C mailing list. Go is easier to
write in general, and it has much better support for the kind of
concurrent programming that is required here.

> golang seems to handle the multiple connections by using light weight
> threads. That seems heavier than epoll(), so any answer that says their are
> equivalent, I would appreciate and explanation of why threads don't cause a
> problem.

Go's networking library is based on epoll too. The "lightweight
threads" make it easier to write correct code to handle multiple
simultaneous connections. The C code to handle multiple connections
in parallel isn't going to be any more efficient than goroutines.

Ian

[Zlatko Calusic]

On 09.08.2015 04:22, golangmike wrote:
> Thank you for the slides Ian.
>
> Let me clarify my questions:
> 1) Will golang have equivalent resource usage as the equivalent program
> written in C/epoll()?
> a) memory
> b) cpu
> c) added delay to communication
> d) maximum number of connections
>

It's hard to compare without knowing how your C/epoll() version does?

For example, I have a simple site behind cloudflare. Some time ago I
rewrote it completely in Go (instead of PHP). Cloudflare keeps
connections to the server open now, since Go supports keepalive by
default, so these days the app has anywhere between 20k and 30k open
connections (see the attached picture). Every connection is a goroutine,
and each one uses about 19KB of memory. The whole app uses 0.1% of CPU
to serve about 15k requests per day. That is of course the remaining
traffic after cloudflare cache.

> 2) Is one easier to write and why?
>
> golang seems to handle the multiple connections by using light weight
> threads. That seems heavier than epoll(), so any answer that says their
> are equivalent, I would appreciate and explanation of why threads don't
> cause a problem.
>
> From my reading, it seems golang seems particularly suitable for this,
> but I would like an experience golang dev confirm that.
>

I'd agree, it was fun to rewrite my app in Go, it's very simple and very
robust. Beside slightly elevated memory usage due to a lot of keepalive
connections (I also had to increase the number of file descriptors
available), the app is very performant.

Regards,
--
Zlatko

[anca.e...@gmail.com]

I think you will need to read this: http://dave.cheney.net/2015/08/08/performance-without-the-event-loop