I am generally a fan of Go's approach to concurrency: writing code with goroutines is a lot easier than writing traditional nonblocking network servers in a language like C or C++. However, while working on a highly concurrent network proxy I came across an interesting realization about how the Go concurrency model makes it harder to write programs that do a lot of concurrent I/O with efficient memory usage.
The program in question is a network proxy akin to HAProxy or Envoy. Typically the proxy has a very large number of clients connected, but most of those clients are actually idle with no outstanding network requests. Each client connection has a read buffer and a write buffer. Therefore the naive memory usage of such a program is at least: #connections * (readbuf_sz + writebuf_sz).
There's a trick you can do in a C or C++ program of this nature to reduce memory usage. Suppose that typically 5% of the client connections are actually active, and the other 95% are idle with no pending reads or writes. In this situation you can create a pool of buffer objects. When connections are actually active they acquire buffers to use for reading/writing from the pool, and when the connections are idle they release the buffers back to the pool. This reduces the number of allocated buffers to approximately the number of buffers actually needed by active connections. In this case using this technique will give a 20x memory reduction, since only 5% as many buffers will be allocated compared to the naive approach.
The reason this technique works at all is due to how nonblocking reads and
writes work in C. In C you use a system call like select(2) or epoll_wait(2)
to get a notification that a file descriptor is read to be read/written, and
then after that you explicitly call read(2) or write(2) yourself on that
file descriptor. This gives you the opportunity to acquire a buffer after the
call to select/epoll, but before making the read call. Here's a simplified
version of the core part of the event loop for a network proxy demonstrating
this technique:
for(;;){// wait for some file descriptors to be read to readintnfds=epoll_wait(epollfd,events,MAX_EVENTS,-1);for(intn=0;n<nfds;n++){// acquire a buffervoid*buf=acquire_buffer(pool);// read the file descriptorintclientfd=events[n].data.fd;ssize_tnbytes=read(clientfd,buf,BUFSIZE);if(nbytes<0){// error casehandle_error(fd,clientfd);}else{// process the requestprocess_read(clientfd,buf,nbytes);}// return the buffer to the poolrelease_buffer(pool,buf);}}
In a synchronous I/O model, such as in a Go program (or a C/C++ program doing blocking I/O with threads) there's no opportunity to get a buffer before doing the read. Instead you supply a buffer to your read call, your goroutine (or thread) blocks until data is ready, and then execution resumes:
// code within the read loop for each connection/goroutinenbytes,err:=conn.Read(buf)
This means that you must have a buffer allocated for each connection: the buffer is supplied to the read call itself, meaning that there must be a buffer associated with each connection that reads may occur on. Unlike with C, in Go there is no way to know if a connection is readable, other than to actually try to read data from it. This means that at the minimum a Go proxy with a large number of mostly idle connections will churn through a large amount of virtual memory space, and likely incur a large RSS memory footprint over time as well.
This isn't the only place where Go's high-level approach to networking reduces efficiency. For instance, Go lacks a way to do vectorized network I/O. If you have ideas on how to solve these problems let me know via email or Twitter and I will update this post.
Update: According
to this GitHub issue it appears
that writev(2) support will appear in Go 1.8, and readv(2) support may
appear one day (but not in 1.8).