Нагрузочный тест на Go, версия 2

[@a696385]

Да, Net In + Net Out == Transfer
В моей версии wrk GET запрос выглядит так

GET /index.html HTTP/1.1\r\n
Host: localhost:3001\r\n
\r\n

в go-meter он чуточку больше

GET /index.html HTTP/1.1\r\n
Host: localhost:3001\r\n
Connection: keep-alive\r\n
\r\n

Но это не причина 20% отставания, так как если прогнать на POST с большим объемом данных, разницы не будет практически никакой, кроме большого объема данных

% ./bin/go-meter -t 7 -c 21 -d 30s -u http://localhost:3001/index.html -m "POST" -s ./bin/source.data
Running test threads: 7, connections: 21 in 30s POST http://localhost:3001/index.html
Stats:            Min       Avg       Max
  Latency           0         0       9ms
  779994 requests in 30.001s, net: in 95MB, out 496MB
HTTP Codes: 
     200       100.00%
Latency: 
        0       100.00%
Requests: 25998.93/sec
Net In: 25MBit/sec
Net Out: 132MBit/sec
Transfer: 20MB/sec

[@sch1z0phr3n1a]

То есть Вы сравниваете тест wrk c Connection: Close vs go-meter с Connection: Keep-Alive?

Вы поступаете очень нечестно, говоря что проигрываете 20% в производительности. Попробуйте потестировать с Connection: Keep-Alive в wrk, и посмотрите на сотни тысяч rps, которые он может легко выжать.

Между connection: close и connection: keep-alive есть очень существенная разница в производительности. Связано это с тем, что не нужно на каждый запрос переоткрывать и закрывать сокеты, а в keep-alive нужно это сделать всего один раз в первом запросе.

[@a696385]

Да я согласен с тем что close и connection: keep-alive есть очень существенная разница в производительности, но тут есть пару но
1. При работе по HTTP 1.1 все соединения считаются постоянными, если не обозначено иное Wikipedia
2. Если посмотреть код wrk, то можно заметить, что соединения открывают один раз при старте потока, далее соединение поддерживается + wrk использует тотже HTTP 1.1

В данной случае разницы между connection: keep-alive и connection: close нет

[@seriyPS]

В http1.1 keep-alive устанавливается по умолчанию. WRK не шлёт connection: close если вы присмотритесь повнимательнее. Хотя я добавлял поддержку свитча с опционально отключаемым keep-alive github.com/seriyps/wrk/blob/master/src/wrk.c#L70 но её не приняли.

[@Moxa]

go get github.com/a696385/go-meter
# github.com/a696385/go-meter/http
/usr/lib/go/src/pkg/github.com/a696385/go-meter/http/request.go:62: bodyReader.WriteTo undefined (type *bufio.Reader has no field or method WriteTo)

что я делаю не так?

[@a696385]

возможно у вас устаревшая версия Go
проверял на

go version go1.1.2 darwin/amd64
go version go1.2rc3 darwin/amd64

[@Moxa]

печаль, у меня go1.0.2

[@Moxa]

если не упираться в сервер, то go-meter раза в два медленнее =(

export GOMAXPROCS=4
$GOPATH/bin/go-meter -c 64 -d 10s -t 4 -u http://localhost:8081/ 
Running test threads: 4, connections: 64 in 10s GET http://localhost:8081/
Stats:            Min       Avg       Max
  Latency           0         0       9ms
  520921 requests in 10s, net: in 49MB, out 33MB
HTTP Codes: 
     200       100.00%
Latency: 
     0       100.00%
Requests: 52092.10/sec
Net In: 39MBit/sec
Net Out: 27MBit/sec
Transfer: 8.2MB/sec

./wrk -t 4 -d 10 -c 64 -H "Connection: Keep-Alive" http://localhost:8081/
Running 10s test @ http://localhost:8081/
  4 threads and 64 connections
  Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency   631.48us    1.04ms  16.68ms   99.02%
    Req/Sec    28.75k     7.13k   64.44k    76.09%
  1083840 requests in 10.00s, 109.56MB read
Requests/sec: 108401.72
Transfer/sec:     10.96MB

[@sch1z0phr3n1a]

Ну вот, теперь больше похоже на правду. И тут явно больше 20%!
Все равно довольно маленький рейт для wrk в 4 потока. Довольно слабенькая машинка? На виртуалку больше похоже:)

[@Moxa]

это мой ноутбук и кастомный сервер на java =)

[@a696385]

Удалось немного увеличить производительность, убрав лишнее и упростив работу с сетью, но работа продолжается, есть большое желание выжать из Go все что можно