inspired by handling 1M websockets connections in Go
- 1_simple_tcp_server: a 1m-connections server implemented based on goroutines per connection
- 2_epoll_server: a 1m-connections server implemented based on epoll
- 3_epoll_server_throughputs: add throughputs and latency test for 2_epoll_server
- 4_epoll_client: 	implement the client based on epoll
- 5_multiple_client: 	use multiple epollto manage connections in client
- 6_multiple_server:  	use multiple epollto manage connections in server
- 7_server_prefork: 	use preforkstyle of apache to implement server
- 8_server_workerpool: use Reactorpattern to implement multiple event loops
- 9_few_clients_high_throughputs: a simple goroutines per connectionserver for test throughtputs and latency
- 10_io_intensive_epoll_server: an io-bound multiple epollserver
- 11_io_intensive_goroutine:  an io-bound goroutines per connectionserver
- 12_cpu_intensive_epoll_server: a cpu-bound multiple epollserver
- 13_cpu_intensive_goroutine:  an cpu-bound goroutines per connectionserver
- two E5-2630 V4cpus, total 20 cores, 40 logicial cores.
- 32G memory
tune the linux:
sysctl -w fs.file-max=2000500
sysctl -w fs.nr_open=2000500
sysctl -w net.nf_conntrack_max=2000500
ulimit -n 2000500
sysctl -w net.ipv4.tcp_tw_recycle=1
sysctl -w net.ipv4.tcp_tw_reuse=1client sends the next request only when it has received the response. it has not used the pipeline style to test.
| throughputs (tps) | latency | |
|---|---|---|
| goroutine-per-conn | 202830 | 4.9s | 
| single epoll(both server and client) | 42495 | 23s | 
| single epoll server | 42402 | 0.8s | 
| multiple epoll server | 197814 | 0.9s | 
| prefork | 444415 | 1.5s | 
| workerpool | 190022 | 0.3s | 
中文介绍: