And how could I generate X TCP requests/min?
On Thursday, May 5, 2016 at 5:03:02 PM UTC+3, Slawomir Pryczek wrote:

From my perspective, most performance hit i got on go side, was from
allocating memory / GC so you should focus on re-using buffers and as
little allocations as possible. Also binary protocols are much faster than
text protocols, parsing is slow.

From network perspective, receive-send back, makes performance to suffer a
lot, if you can just send the messages, and then receive confirmation that
they were processed correctly, in bulk later, it'll be much faster (from my
test sending in bulk makes it like 5-20 TIMES faster)... but don't know if
your use case will allow it. If you send single message, and then wait for
a response from server it'll burn CPU cycles like crazy.

You can look at my implementation here:

This is using TCP_NODELAY because of receive-send back model, but also
enabling / disabling TCP_NODELAY will make a lot of difference depends on
network type and MTU.

W dniu czwartek, 5 maja 2016 15:13:01 UTC+2 użytkownik Rayland napisał:
I have a client that will send around 500k requests (messages) / min.
Each request will contain a payload of 200 bytes to 2 KB in size. Each
payload will be saved in a database (probably Couchbase).

What is the correct approach to build a TCP server that will handle this
load in a resource efficient way?

I'm not sure how to fully utilise the machine resources (taking advantage
of multicore processors), and how to structure the server in terms of
ports, connections, goroutines and cores.
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 24 | next ›
Discussion Overview
groupgolang-nuts @
postedMay 5, '16 at 1:13p
activeMay 10, '16 at 3:15p



site design / logo © 2021 Grokbase