А есть кто интересуется разработкой на Go?
Привет коллеги, предлагаю создать сообщество, собираться периодически, обмениваться опытом, идеями по Go.
Alex Danilov, Senior software engineer
Facebook
Twitter
LinkedIn
Iryna Recruiter
-
Svetlana Malezhyk
-
Mucola Demchenco
А що можна написати на go (навчальний проект)?
Nataliya Burenok
Кому актуально набираємо GoLang Trainee в Харкові. Всі деталі в LinkedIn або Skype: live:burenok_3
Pavel Matvienko
Нам нужен Go Full Stack разработчик.
Стек: Go / ReactJS / JS
Мы развиваем продукт под названием RetargetApp — приложение для e-commerce платформ (Shopify, BigCommerce) и т.д. Наше приложение помогает владельцам интернет-магазинов автоматизировать создание и повышать эффективность ретаргетинговых кампаний в Facebook и Instagram
Детальнее: jobs.dou.ua/…argetapp/vacancies/33180
Dmytro Klymenko
Мы сейчас ищем к себе Golang программиста для работы над Demand Side Platform. Если интересно — свяжитесь со мной через linkedin или через DOU.
Oleh Herych
Використовується на проекті. Чуток бавлюсь з Го в домашніх умовах
Yuliia Zolotarenko
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Igor Lushchyk
писав на пітоні і рубі, сішка якось не йшла — але от го йде по повній , втягує потроху.
Єдине , що незвичне так це — ерор хендлінг , а так суперська річ
reality_hacker
Коментар порушує правила спільноти і видалений модераторами.
Igor Lushchyk
Коментар порушує правила спільноти і видалений модераторами.
Коментар порушує правила спільноти і видалений модераторами.
Snk Ys
Очень крутой язык, недавно пытался штурмовать книгу, ну знаете, такая с оленем, времени пока не хватило на полное осиляторство, но общий концепт и работы Фиори ( github.com/fiorix ) впечатляют — парень переписал freegeoip.net c python/twisted на Go и ничего не боится.
Aliaksandr Valialkin
Я интересуюсь и даже пишу кое-что на go:
— github.com/...valyala/goloris — slowloris для nginx
— github.com/.../go/cdn-booster — быстрый кэширующий http-прокси для статического контента небольших размеров (картинки, js, css, mp3). Быстрее nginx’а :)
— github.com/...ps/go/memcached — memcache-совместимый сервер с прозрачной поддержкой persistence, объем кэша может превышать объем оперативной памяти в десятки раз, размер кэшируемых объектов не ограничен 2Мб, в отличие от memcached.
Igor Petruk
Точно быстрее тюнингованого nginxа?
Aliaksandr Valialkin
Я не спец в тюнинге nginx’а.
В моих синтетическах тестах go-cdn-booster работает быстрее nginx’а при следующих настройках:
go-cdn-booster:
./go-cdn-booster -upstreamHost=www.google.com -maxConnsPerIp=64 -cacheFilesPath=/var/www/cache2
nginx:
keepalive_requests 10000000; proxy_cache_path /var/www/cache levels=1:2 keys_zone=my-cache:100k max_size=100m inactive=600m; proxy_temp_path /var/www/cache/tmp; proxy_pass http://www.google.com; proxy_cache_valid 200 60m; proxy_cache my-cache;
Тесты проводились с помощью программы go-cdn-booster-bench, также, как нетрудно догадаться, написанной на go:
Тест nginx:
$ ./go-cdn-booster-bench -testUrl=http://localhost:80/images/srpr/logo11w.png -requestsCount=300000 -workersCount=64 goMaxProcs=4 requestsCount=300000 testUrl=http://localhost:80/images/srpr/logo11w.png workersCount=64 2014/02/19 08:51:37 Test started 2014/02/19 08:51:46 Done 2014/02/19 08:51:46 300000 requests from 64 workers in 9.54066905s 2014/02/19 08:51:46 31444 qps, 453679 Kbps
Тест go-cdn-booster:
$ ./go-cdn-booster-bench -testUrl=http://localhost:8098/images/srpr/logo11w.png -requestsCount=300000 -workersCount=64 goMaxProcs=4 requestsCount=300000 testUrl=http://localhost:8098/images/srpr/logo11w.png workersCount=64 2014/02/19 08:51:54 Test started 2014/02/19 08:51:57 Done 2014/02/19 08:51:57 300000 requests from 64 workers in 3.388799157s 2014/02/19 08:51:57 88527 qps, 1254515 Kbps
Выводы делайте сами.
Gabriel Angelos
Синтетика это конечно круто, но получить отрыв в 281% по сравнению с промышленным стандартом смахивает на сказку. Возможно, стоит протестировать в реальных условиях?
А что твои прокси и мемкешед делают когда у го включается stop the world garbage collector?
Нестор Иванович
Вроде работают без тормозов.
Вот результаты сравнительных тестов go-memcached (порт 11212) против memcached (порт 11211) с помощью программы go-memcached-bench:
cache-miss
$ ./go-memcached-bench -serverAddrs=localhost:11212 -workerMode=GetMiss
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=20ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11212
valueSize=200
workerMode=GetMiss
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 2ms: 5.854% ###
2ms - 4ms: 7.121% ####
4ms - 6ms: 7.295% ####
6ms - 8ms: 13.178% #######
8ms - 10ms: 21.906% #############
10ms - 12ms: 20.414% ############
12ms - 14ms: 11.816% #######
14ms - 16ms: 4.267% ##
16ms - 18ms: 2.423% #
18ms -1h0m0s: 5.727% ###
Requests per second: 407204
Test duration: 2.455773052s
Avg response time: 9.662755ms
Min response time: 30.761us
Max response time: 40.754728ms
Cache miss count: 1000000
Cache hit count: 0
Cache miss ratio: 100.000%
Errors count: 0
$ ./go-memcached-bench -serverAddrs=localhost:11211 -workerMode=GetMiss
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=20ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=200
workerMode=GetMiss
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 2ms: 7.520% ####
2ms - 4ms: 7.327% ####
4ms - 6ms: 6.481% ###
6ms - 8ms: 9.386% #####
8ms - 10ms: 12.094% #######
10ms - 12ms: 14.727% ########
12ms - 14ms: 12.960% #######
14ms - 16ms: 7.287% ####
16ms - 18ms: 5.089% ###
18ms -1h0m0s: 17.129% ##########
Requests per second: 173068
Test duration: 5.778064757s
Avg response time: 23.349264ms
Min response time: 23.972us
Max response time: 219.261123ms
Cache miss count: 1000000
Cache hit count: 0
Cache miss ratio: 100.000%
Errors count: 0
cache hit:
$ ./go-memcached-bench -serverAddrs=localhost:11212 -maxResponseTime=50ms -workerMode=GetHit
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=50ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11212
valueSize=200
workerMode=GetHit
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 5ms: 7.852% ####
5ms - 10ms: 12.609% #######
10ms - 15ms: 16.092% #########
15ms - 20ms: 15.300% #########
20ms - 25ms: 13.315% #######
25ms - 30ms: 14.395% ########
30ms - 35ms: 10.841% ######
35ms - 40ms: 5.294% ###
40ms - 45ms: 2.570% #
45ms -1h0m0s: 1.732% #
Requests per second: 195700
Test duration: 4.994024613s
Avg response time: 20.27249ms
Min response time: 35.068us
Max response time: 81.157051ms
Cache miss count: 22668
Cache hit count: 977332
Cache miss ratio: 2.267%
Errors count: 0
$ ./go-memcached-bench -serverAddrs=localhost:11211 -maxResponseTime=50ms -workerMode=GetHit
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=50ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=200
workerMode=GetHit
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 5ms: 13.824% ########
5ms - 10ms: 13.091% #######
10ms - 15ms: 14.725% ########
15ms - 20ms: 12.219% #######
20ms - 25ms: 10.299% ######
25ms - 30ms: 10.332% ######
30ms - 35ms: 7.666% ####
35ms - 40ms: 5.125% ###
40ms - 45ms: 2.662% #
45ms -1h0m0s: 10.058% ######
Requests per second: 127611
Test duration: 7.836205096s
Avg response time: 31.276171ms
Min response time: 23.363us
Max response time: 262.202889ms
Cache miss count: 13
Cache hit count: 999987
Cache miss ratio: 0.001%
Errors count: 0
cache set:
$ ./go-memcached-bench -serverAddrs=localhost:11212 -maxResponseTime=50ms -workerMode=Set
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=50ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11212
valueSize=200
workerMode=Set
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 5ms: 14.660% ########
5ms - 10ms: 28.087% ################
10ms - 15ms: 33.102% ###################
15ms - 20ms: 15.665% #########
20ms - 25ms: 5.600% ###
25ms - 30ms: 1.667% #
30ms - 35ms: 0.922%
35ms - 40ms: 0.286%
40ms - 45ms: 0.010%
45ms -1h0m0s: 0.000%
Requests per second: 347328
Test duration: 2.879125567s
Avg response time: 11.482975ms
Min response time: 31.333us
Max response time: 43.29533ms
Cache miss count: 0
Cache hit count: 0
Cache miss ratio: 0.000%
Errors count: 0
$ ./go-memcached-bench -serverAddrs=localhost:11211 -maxResponseTime=50ms -workerMode=Set
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=50ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=200
workerMode=Set
workersCount=4096
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 5ms: 8.575% #####
5ms - 10ms: 17.683% ##########
10ms - 15ms: 19.787% ###########
15ms - 20ms: 18.217% ##########
20ms - 25ms: 13.677% ########
25ms - 30ms: 8.367% #####
30ms - 35ms: 6.126% ###
35ms - 40ms: 3.011% #
40ms - 45ms: 1.974% #
45ms -1h0m0s: 2.584% #
Requests per second: 219066
Test duration: 4.564834956s
Avg response time: 18.503356ms
Min response time: 30.492us
Max response time: 214.13269ms
Cache miss count: 0
Cache hit count: 0
Cache miss ratio: 0.000%
Errors count: 0
Выводы делайте сами.
У тебя какие то микро бенчмарки, там наверняка ГЦ даже не включился потому что все элементарно помещается в памяти. Сделай айтемы по 100КБ (веб страница) сделай миллиард запросов, и 100 млн уникальных айтемов.
Ну и твой Г-код поддерживать врагу не посоветуешь.
Точнее миллиард запросов это слегка дофига. Можно 10 миллионов и миллион айтемов.
100 кб для айтема — слишком много. Тут производительность упрется в пропускную способность памяти, а в реальных условиях — в пропускную способность канала связи. На моем компе производительность ограничена 5к запросами в секунду как для memcached, так и для go-memcached.
К тому, исходя из моего опыта, в memcached обычно хранятся не html-страницы (для этого лучше подходит go-cdn-booster :)), а более мелкие айтемы. Например, небольшие списки айдишек либо строк или небольшие блоки html-кода. Т.е. размер айтема редко превышает 1кб.
Вот результаты тестов для 1кб айтемов. Надеюсь, тут gc сработал — ведь нужно «прокачать» минимум 10М*1Кб=10Гб памяти.
- 10 миллионов запросов на создание 1кб айтемов, используя миллион различных ключей:
memcached:$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=1000 -itemsCount=1000000 -requestsCount=10000000 -serverAddrs=localhost:11211 -workerMode=Set Config: clientType=new connectionsCount=4 getRatio=0.9 goMaxProcs=4 ioTimeout=10s itemsCount=1000000 keySize=30 maxPendingRequestsCount=4096 maxResponseTime=500us osReadBufferSize=229376 osWriteBufferSize=229376 readBufferSize=57344 requestsCount=10000000 responseTimeHistogramSize=10 serverAddrs=localhost:11211 valueSize=1000 workerMode=Set workersCount=32 writeBufferSize=57344 Preparing...done starting...done Response time histogram 0 - 50us: 2.280% # 50us - 100us: 12.980% ####### 100us - 150us: 17.241% ########## 150us - 200us: 19.377% ########### 200us - 250us: 16.497% ######### 250us - 300us: 11.886% ####### 300us - 350us: 7.440% #### 350us - 400us: 4.266% ## 400us - 450us: 2.401% # 450us -1h0m0s: 5.632% ### Requests per second: 132652 Test duration: 1m15.385073951s Avg response time: 238.194us Min response time: 20.495us Max response time: 35.115358ms Cache miss count: 0 Cache hit count: 0 Cache miss ratio: 0.000% Errors count: 0go-memcached:$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=1000 -itemsCount=1000000 -requestsCount=10000000 -serverAddrs=localhost:11212 -workerMode=Set Config: clientType=new connectionsCount=4 getRatio=0.9 goMaxProcs=4 ioTimeout=10s itemsCount=1000000 keySize=30 maxPendingRequestsCount=4096 maxResponseTime=500us osReadBufferSize=229376 osWriteBufferSize=229376 readBufferSize=57344 requestsCount=10000000 responseTimeHistogramSize=10 serverAddrs=localhost:11212 valueSize=1000 workerMode=Set workersCount=32 writeBufferSize=57344 Preparing...done starting...done Response time histogram 0 - 50us: 1.076% 50us - 100us: 15.249% ######### 100us - 150us: 39.057% ####################### 150us - 200us: 25.207% ############### 200us - 250us: 11.972% ####### 250us - 300us: 3.817% ## 300us - 350us: 1.274% 350us - 400us: 0.588% 400us - 450us: 0.321% 450us -1h0m0s: 1.440% Requests per second: 192631 Test duration: 51.91281302s Avg response time: 163.343us Min response time: 18.762us Max response time: 12.010048ms Cache miss count: 0 Cache hit count: 0 Cache miss ratio: 0.000% Errors count: 0
10 миллионов запросов на чтение из миллиона айтемов по 1кб каждый:
memcached:$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=1000 -itemsCount=1000000 -requestsCount=10000000 -serverAddrs=localhost:11211 -workerMode=GetHit Config: clientType=new connectionsCount=4 getRatio=0.9 goMaxProcs=4 ioTimeout=10s itemsCount=1000000 keySize=30 maxPendingRequestsCount=4096 maxResponseTime=500us osReadBufferSize=229376 osWriteBufferSize=229376 readBufferSize=57344 requestsCount=10000000 responseTimeHistogramSize=10 serverAddrs=localhost:11211 valueSize=1000 workerMode=GetHit workersCount=32 writeBufferSize=57344 Preparing...done starting...done Response time histogram 0 - 50us: 2.286% # 50us - 100us: 12.201% ####### 100us - 150us: 22.486% ############# 150us - 200us: 25.969% ############### 200us - 250us: 16.410% ######### 250us - 300us: 8.935% ##### 300us - 350us: 4.151% ## 350us - 400us: 2.220% # 400us - 450us: 1.309% 450us -1h0m0s: 4.034% ## Requests per second: 66553 Test duration: 1m6.527642454s Avg response time: 213.235us Min response time: 19.415us Max response time: 27.464948ms Cache miss count: 5572402 Cache hit count: 4427598 Cache miss ratio: 55.724% Errors count: 0go-memcached:$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=1000 -itemsCount=1000000 -requestsCount=10000000 -serverAddrs=localhost:11212 -workerMode=GetHit Config: clientType=new connectionsCount=4 getRatio=0.9 goMaxProcs=4 ioTimeout=10s itemsCount=1000000 keySize=30 maxPendingRequestsCount=4096 maxResponseTime=500us osReadBufferSize=229376 osWriteBufferSize=229376 readBufferSize=57344 requestsCount=10000000 responseTimeHistogramSize=10 serverAddrs=localhost:11212 valueSize=1000 workerMode=GetHit workersCount=32 writeBufferSize=57344 Preparing...done starting...done Response time histogram 0 - 50us: 1.162% 50us - 100us: 11.050% ###### 100us - 150us: 26.527% ############### 150us - 200us: 29.842% ################# 200us - 250us: 18.321% ########## 250us - 300us: 6.570% ### 300us - 350us: 2.271% # 350us - 400us: 1.075% 400us - 450us: 0.637% 450us -1h0m0s: 2.545% # Requests per second: 75072 Test duration: 58.933025638s Avg response time: 189.271us Min response time: 20.846us Max response time: 13.977799ms Cache miss count: 5575757 Cache hit count: 4424243 Cache miss ratio: 55.758% Errors count: 0
К тому же у memcached есть одна неприятная вещь под названием memcache slab calcification, которая проявляется в том, что если мемкэш полностью заполнен айтемами одного размера, а потом внезапно мы решим заполнить его айтемами другого размера, то у memcached’а проявится склероз — он не будет запоминать новые айтемы :)
Вот как это легко проявляется с помощью go-memcached-bench:
заполняем кэш айтемами по 1кб
$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=1000 -itemsCount=450000 -requestsCount=1000000 -serverAddrs=localhost:11211 -workerMode=GetHit
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=450000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=500us
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=1000
workerMode=GetHit
workersCount=32
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 50us: 2.163% #
50us - 100us: 10.421% ######
100us - 150us: 14.800% ########
150us - 200us: 19.111% ###########
200us - 250us: 18.670% ###########
250us - 300us: 12.948% #######
300us - 350us: 8.095% ####
350us - 400us: 4.442% ##
400us - 450us: 2.412% #
450us -1h0m0s: 6.939% ####
Requests per second: 119388
Test duration: 8.237937785s
Avg response time: 260.207us
Min response time: 19.285us
Max response time: 43.430137ms
Cache miss count: 16485
Cache hit count: 983515
Cache miss ratio: 1.648%
Errors count: 0
теперь безуспешно пытаемся заполнить кэш айтемами по 500 байт. Обратите внимание на cache miss ratio:
$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=500 -itemsCount=450000 -requestsCount=1000000 -serverAddrs=localhost:11211 -workerMode=GetHit
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=450000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=500us
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=500
workerMode=GetHit
workersCount=32
writeBufferSize=57344
Preparing...done
starting...2014/02/21 11:17:08 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:17:08 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:17:08 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:17:08 Cannot write 5 bytes to output stream: [use of closed network connection]
2014/02/21 11:17:08 Cannot write 5 bytes to output stream: [use of closed network connection]
2014/02/21 11:17:08 Cannot write 5 bytes to output stream: [use of closed network connection]
done
Response time histogram
0 - 50us: 0.000%
50us - 100us: 4.839% ##
100us - 150us: 22.903% #############
150us - 200us: 38.387% #######################
200us - 250us: 20.323% ############
250us - 300us: 4.194% ##
300us - 350us: 3.548% ##
350us - 400us: 0.323%
400us - 450us: 0.645%
450us -1h0m0s: 4.839% ##
Requests per second: 213
Test duration: 1.458769672s
Avg response time: 245.41us
Min response time: 61.059us
Max response time: 2.907143ms
Cache miss count: 91434
Cache hit count: 310
Cache miss ratio: 99.662%
Errors count: 908256
теперь безуспешно пытаемся заполнить кэш айтемами по 2кб:
$ ./go-memcached-bench -workersCount=32 -maxResponseTime=0.5ms -valueSize=2000 -itemsCount=450000 -requestsCount=1000000 -serverAddrs=localhost:11211 -workerMode=GetHit
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=450000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=500us
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=localhost:11211
valueSize=2000
workerMode=GetHit
workersCount=32
writeBufferSize=57344
Preparing...done
starting...2014/02/21 11:19:31 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:19:31 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:19:31 Cannot write 5 bytes to output stream: [use of closed network connection]
2014/02/21 11:19:31 Cannot write 5 bytes to output stream: [use of closed network connection]
2014/02/21 11:19:31 Unexpected line read=[ERROR]. It should start with [VALUE ]
2014/02/21 11:19:31 Cannot write 5 bytes to output stream: [use of closed network connection]
done
Response time histogram
0 - 50us: 0.000%
50us - 100us: 5.208% ###
100us - 150us: 16.667% #########
150us - 200us: 30.208% ##################
200us - 250us: 19.792% ###########
250us - 300us: 13.542% ########
300us - 350us: 3.125% #
350us - 400us: 2.083% #
400us - 450us: 3.125% #
450us -1h0m0s: 6.250% ###
Requests per second: 57
Test duration: 1.698048474s
Avg response time: 260.033us
Min response time: 78.834us
Max response time: 1.988618ms
Cache miss count: 91066
Cache hit count: 96
Cache miss ratio: 99.895%
Errors count: 908838
У go-memcached такой болезни нет.
Реальные аппликухи не работают на слабеньких компах.
Попробуйте потестить в облаке хотя бы.
Думаю, что over 100к запросов в секунду на слабеньком компе покроют нужды 99% высоконагруженных проектов в интернете. Поэтому не вижу смысла в тестах на более мощных компах.
На моем компе производительность ограничена 5к запросами в секунду как для memcached, так и для go-memcached.Ваши слова?
Как 5к так быстро превратились в 100к ?
Думаю, что over 100к запросов в секунду на слабеньком компе покроют нужды 99% высоконагруженных проектов в интернете.Сами хоть понимаете, что бред написали?
Это ж в стиле Бабушкина: «сжать фильм в миллион/миллиард раз»
Как 5к так быстро превратились в 100к ?Может, стоит еще раз прочесть мой комментарий вместо того, чтобы выдергивать фразы из контекста?
Сами хоть понимаете, что бред написали?Не понимаю. Давайте проведем небольшой расчет. Согласно статистике, сайтом «вконтакте» пользуются 60 миллионов посетителей в сутки. Сколько запросов на одного посетителя в сутки сможет обработать сферический go-memcached на слабом компе (в вакууме) с производительностью 100к запросов в секунду? 100К*3600*24/60М=144 запроса в сутки. На всех может не хватить :) Значит, вконтакте входит в тот самый 1% высоконагруженных сайтов, которым мало одного мемкеш-сервера :)
John Doe
Не понимаю.Это заметно (
Впрочем можете попробовать убедить Вконтактик потестить ваше поделие. Узнаете много нового. В частности какой характер бывает у реальной нагрузки.
Про характер реальной нагрузки у меня есть интересная статья, в которой почему-то поехало форматирование. Когда я ее писал, с форматированием было все ок.
Опыт важнее статей. В статье лишь часть важного. Да и статья не слишком удачна, извините.
Главная проблема в том, что поток тестовых запросов не является Пуассоновским процессомДа, это главная проблема статьи) — проблема того, что реальная нагрузка также далека от Пуассоновских потоков — вы упустили основное, реальная нагрузка может быть совершенно неоднородна.
Пуассо́на пото́к (проце́сс) — ординарный поток однородных событий
Выдержка из статьи на википедии про пуассоновский процесс:
The following examples are also well-modeled by the Poisson process:
...
— Requests for individual documents on a web server
Мне вот еще что интересно, почему ты тестируешь сценарий: вначале засунем 10млн записей, а потом прочтем 10млн записей. Тебе не кажется что в реальной жизни трафик слегка смешанный?
Вот результаты тестов по смешанному трафику — 90% чтение, 10% запись (см. параметры workerMode и getRatio):
memcached:
$ ./go-memcached-bench -maxResponseTime=1ms -workersCount=32 -serverAddrs=127.0.0.1:11211 -workerMode=GetSet
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=1ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=127.0.0.1:11211
valueSize=200
workerMode=GetSet
workersCount=32
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 100us: 7.094% ####
100us - 200us: 23.259% #############
200us - 300us: 34.651% ####################
300us - 400us: 17.681% ##########
400us - 500us: 7.689% ####
500us - 600us: 2.908% #
600us - 700us: 1.372%
700us - 800us: 0.786%
800us - 900us: 0.537%
900us -1h0m0s: 4.023% ##
Requests per second: 84233
Test duration: 11.871691529s
Avg response time: 375.705us
Min response time: 24.086us
Max response time: 49.169658ms
Cache miss count: 10
Cache hit count: 899878
Cache miss ratio: 0.001%
Errors count: 0
go-memcached:
$ ./go-memcached-bench -maxResponseTime=1ms -workersCount=32 -serverAddrs=127.0.0.1:11212 -workerMode=GetSet
Config:
clientType=new
connectionsCount=4
getRatio=0.9
goMaxProcs=4
ioTimeout=10s
itemsCount=100000
keySize=30
maxPendingRequestsCount=4096
maxResponseTime=1ms
osReadBufferSize=229376
osWriteBufferSize=229376
readBufferSize=57344
requestsCount=1000000
responseTimeHistogramSize=10
serverAddrs=127.0.0.1:11212
valueSize=200
workerMode=GetSet
workersCount=32
writeBufferSize=57344
Preparing...done
starting...done
Response time histogram
0 - 100us: 9.814% #####
100us - 200us: 35.089% #####################
200us - 300us: 34.599% ####################
300us - 400us: 12.767% #######
400us - 500us: 3.138% #
500us - 600us: 1.341%
600us - 700us: 0.716%
700us - 800us: 0.428%
800us - 900us: 0.307%
900us -1h0m0s: 1.802% #
Requests per second: 118365
Test duration: 8.305726463s
Avg response time: 261.493us
Min response time: 23.009us
Max response time: 38.978721ms
Cache miss count: 16896
Cache hit count: 883178
Cache miss ratio: 1.877%
Errors count: 0
У меня получаются абсолютно идентичные цифры с легким перевесом в пользу мемкеша и с значительно лучшими резултатами в плане cache missed ratio:
memcached:
memcached -t 12 -c 22288 -m 140
Response time histogram
0 - 100us: 50.758% ##############################
100us - 200us: 36.667% ######################
200us - 300us: 8.358% #####
300us - 400us: 2.246% #
400us - 500us: 0.729%
500us - 600us: 0.265%
600us - 700us: 0.106%
700us - 800us: 0.051%
800us - 900us: 0.024%
900us -1h0m0s: 0.796%
Requests per second: 62737
Test duration: 10.154665976s
Avg response time: 164.866us
Min response time: 26.222us
Max response time: 63.195655ms
Cache miss count: 1362928
Cache hit count: 436648
Cache miss ratio: 75.736%
Errors count: 0
gomemcache:
Preparing...done
starting...done
Response time histogram
0 - 100us: 63.424% ######################################
100us - 200us: 28.548% #################
200us - 300us: 5.205% ###
300us - 400us: 1.646%
400us - 500us: 0.592%
500us - 600us: 0.232%
600us - 700us: 0.085%
700us - 800us: 0.037%
800us - 900us: 0.023%
900us -1h0m0s: 0.209%
Requests per second: 62551
Test duration: 6.663772302s
Avg response time: 109.628us
Min response time: 25.987us
Max response time: 9.972696ms
Cache miss count: 1583177
Cache hit count: 216845
Cache miss ratio: 87.953%
./memcached-bench -maxResponseTime=1ms -workersCount=32 -serverAddrs=127.0.0.1:11211 -workerMode=GetSet -itemsCount=2000000 -requestsCount=2000000 -<blockquote>getRatio=0.9</blockquote>
При этом если я пытаюсь увеличить количество айтемов или реквестов, твоя гавнопрограмма падает с ошибками вроде: panic: runtime error: makeslice: len out of rangeСпасибо за багрепорт — исправил.
Насчет большого количество cache miss ratio у go-memcached-bench — попробуйте увеличить количество памяти под кэш ( параметр cacheSize, значение по умолчанию 64 Мб) и максимальное количество айтемов, которые может запомнить кэш ( параметр maxItemsCount, значение по умолчанию 1М ). А не то вы пытаетесь записать в маленький кэш 2М айтемов.
Я выставил мемкешу столько же памяти сколько потребляет твое поделие, то что твое решение менее рационально использует память, не моя вина.
Мне удалось воспроизвести ваши результаты по Cache miss ratio только при maxItemsCount=1M. Если же запустить go-memcached с maxItemsCount=2M, то Cache miss ratio снизится до 74%, а количество запросов в секунду увеличится на 30%.
Также столь высокий уровень кэш-промахов получается из-за того, что вы пытаетесь записать valueSize*itemsCount=200*2M=400Mб данных в 140Мб памяти.
Мне удалось воспроизвести ваши результаты по Cache miss ratio только при maxItemsCount=1M. Если же запустить go-memcached с maxItemsCount=2M, то Cache miss ratio снизится до 74%, а количество запросов в секунду увеличится на 30%.Я попробовал, но оно и памяти стало кушать намного больше, т.е. я считаю корректным предыдущий бенчмарк, когда оба кеша едят одинаково памяти.
Также столь высокий уровень кэш-промахов получается из-за того, что вы пытаетесь записать valueSize*itemsCount=200*2M=400Mб данных в 140Мб памяти.Ну да, это ведь кеш а не in memory db.
Ну и твой Г-код поддерживать врагу не посоветуешь.
- Разместите, пожалуйста, ссылку на мой говнокод с обоснованием, почему вы считаете это говнокодом.
- Сравните мой говнокод с кодом memcached или всеми любимой "супер"-программы ab
- Приведите ссылки на ваш не-говнокод
Иначе кто-то из нас пиздобол :)
Ты смешной такой, у тебя там 80% текста — копипаст одного и тогоже куска текста, зачем функции в программировании нужны ты еще в школе не проходил??
defer wg.Done()
var item memcache_new.Item
for _ = range ch {
n := rand.Intn(*itemsCount)
item.Key = []byte(fmt.Sprintf("miss_%s_%d", key, n))
startTime := time.Now()
if err := client.Get(&item); err != memcache_new.ErrCacheMiss {
stats.errorsCount++
continue
}
stats.cacheMissCount++
updateResponseTimeHistogram(stats, startTime)
}
Наверное для вызова функции/метода тратится АЖ ОДИН дополнительный такт процессора, а копипаста спасает от этого :-)
Если бы, все эти копипасты таки завернуты в отдельные функции
Тогда виноват, ошибся.
А что тогда бенчмарк показывает когда демонстирует почти
Я хочу сам как нибудь на досуге поиграться с его бенчмарком, тогда и посмотрим.
Но вообще мемкешед слегка сложнее штуковина чем его кеш, оно например поддерживат compare and swap и еще кучу команд
Но вообще мемкешед слегка сложнее штуковина чем его кеш, оно например поддерживат compare and swap и еще кучу командОпять кто-то пиздоболит. go-memcached поддерживает compare and swap — см. github.com/.../server.go#L449 . go-memcached не поддерживает только совсем никому не нужные команды — см. FAQ в github.com/...memcache/README .
Звиздец, это уже диагноз, я должен шарится по срц-ам что бы посмотреть АПИ? Ну и то что ты 80% АПИ назвал ненужным тоже как бы показательно.
Ты смешной такой, у тебя там 80% текста — копипаст одного и тогоже куска текста, зачем функции в программировании нужны ты еще в школе не проходил??
Я не знаю, как тут без копипасты обойтись. Может, покажешь? Присылай pull request или на худой конец сюда скинь небольшой кусочек кода, чтобы я уловил идею.
У тебя не хватает ума додуматься как можно слить две практически одинаковые функции? Это прекрасно.
К сожалению не хватает. Буду признателен за вашу помощь!
Коментар порушує правила спільноти і видалений модераторами.
быстрый кэширующий http-прокси для статического контента небольших размеров (картинки, js, css, mp3). Быстрее nginx’а :)Вот после этой фразы сразу возникает вопрос: что такое по вашему nginx, какие его основные функции и преимущества — и для чего его используют.
И только не надо про «быстрее», «быстрый». Без понимания подобного нет смысла использовать его для сравнения.
Я имел ввиду, что go-cdn-booster быстрее nginx’а в роли кэшрующего http-прокси для статического контента. Выше приведены сравнительные результаты тестов для go-cdn-booster’а и nginx’а именно в этой роли.
Пройдемся по основным преимуществам nginx’а, применимым к роли кэширующего http-прокси для статического контента.
- Умение одновременно обрабатывать большое количество http-подключений, потребляя при этом мало памяти и процессорных ресурсов. Go-cdn-booster также может спокойно обрабатывать десятки тысяч одновременных подключений, благодаря лековесным потокам — goroutines, встроенным в Go. Конечно, при этом он будет потреблять немного больше userspace памяти, чем nginx (4кб или 8кб на одно подключение против пары сотен байт, декларируемых разработчиками nginx). Это значит, что для 100к одновременных подключений go-cdn-booster будет «жрать» 400-800Мб памяти, в то время как nginx — в районе 100Мб. Но не стоит забывать, что речь идет про userspace память. Если вспомнить про то, что для каждого подключения операционная система обычно выделяет пару десятков или даже сотен Кб kernelspace памяти под буферы чтения/записи, то вышеупомянутыми расходами памяти в userspace можно пренебречь.
- «Защита» upstream серверов, стоящих за nginx, от клиентов, которые могут медленно отправлять запросы и также медленно принимать ответы, удерживая при этом «драгоценные» ресурсы серверов в виде процессов и/или потоков, которые в это время могли бы обрабатывать другие запросы. Эта защита осуществляется путем полной буферизации запросов от клиентов перед тем, как отправить их upstream серверам, а также путем полной буферизации ответов от upstream серверов перед тем, как отправить их клиентам. Go-cdn-booster аналогичным образом защищает upstream сервера.
Кроме того, go-cdn-booster предоставляет дополнительные возможности, отсутствующие в nginx либо в его настройках по умолчанию:
- Лекгая расширяемость под произвольные нужды. Чтобы понять, почему функциональность go-cdn-booster проще «расширить» по сравнению с nginx:
- сравните ~350 строчек кода go-cdn-booster с 100500 строчек исходников nginx.
- сравните модель программирования «один запрос в одном потоке», использующейся в go-cdn-booster, с моделью программирования «event loop», использующейся в nginx’е
- сравните Go, на котором написан go-cdn-booster, с C, на котором написан nginx
- Встроенная защита от dopile эффекта, когда одновременно приходят несколько запросов к одному и тому же файлу, который еще не закэширован. Без этой защиты прокси отправляет одновременно много запросов к одному файлу на upstream сервере. С защитой отправляется лишь один запрос, а остальные ждут, пока запрашиваемый файл не появится в кэше.
- Встроенная защита от slowloris DoS-атак, которые нацелены на исчерпание и удержание ограниченных ресурсов сервера. У nginx’а таким ресурсом является максимальное количество одновременно обрабатываемых подключений (параметр worker_connections, который по умолчанию установлен в 512 на один worker процесс). Желающие могут легко убедиться в этом с помощью программы goloris.
сравните ~350 строчек кода go-cdn-boosterНе-не-не, зачем опять лапшу на уши вешать, невооруженным глазом видно что бустер тянет за собой кучу гавнокода из ybc.
ybc — это библиотека функций для кэширования. Для расширения функциональности http-прокси вряд ли придется копаться внутри этой библиотеки.
Если следовать вашей логике, то «невооруженным глазом видно, что бустер тянет за собой кучу гавнококода из bufio, flag, fmt, io, log, net, runtime, strconv, strings, sync, time, а nginx тянет за собой кучу говнокода из стандартных библиотек C».
Для расширения функциональности http-прокси вряд ли придется копаться внутри этой библиотеки.Не понял, твое поделие уже претендует на отсутствие ошибок и протестированность на 100500 миллионах продакшн деплойментов как в случае с nginx?
Если следовать вашей логике, то «невооруженным глазом видно, что бустер тянет за собой кучу гaвнoкокода из bufio, flag, fmt, io, log, net, runtime, strconv, strings, sync, time, а nginx тянет за собой кучу гвнокода из стандартных библиотек C».В нгинкс как раз большинство из того что ты перечислил уже включено тобой в «100500 строчек исходников» в github.com/...master/src/core, так что да, твое сравнение становится еще более некоректным.
Перечитайте пожалуйста внимательно мой комент.
Желаю успеха в продвижении и попадании на продакшн реальных больших проектов.
Однако для этого стоит учитывать не только собственных критерии оценки.
reality_hacker
Bohdan Chechyn
компилится заметно быстрее:)
Я весь проект перекомпиливаю максимум раз в день, а ты любишь компилить целыми днями?
Что еще?
Макс Матюхин
у go талисман няшный
Я бы предпочел секси подругу а не хорька. Хотя каждому свое, на вкус и цвет..
schwarzlichtbezirk
а секси-подруга предпочтёт хорька, так что go — вне конкуренции.
отсутвием нормльной поддержки зависимостей лол
Kostya Golikov
Временем старта (если бы я писал какую-то консольную тулзу, тот же мавен, я бы предпочел бы не-jvm язык, про nailgun в курсе), меньшим количеством концепций языка.
Временем старта (если бы я писал какую-то консольную тулзу, тот же мавен, я бы предпочел бы не-jvm язык, про nailgun в курсе)Ну да, где то там и есть ниша го, толкаться с питоном и руби в области консольных тулзей на 50 строк кода.
меньшим количеством концепций языка.Мне это вообще понравилось, эти извращенцы выкинули ексепшны и дженерики, как без них жить?
Mykola Gurov
Вам туда, где скала лучше : dou.ua/forums/topic/16012
Bohdan Chechyn
Bogdan Shyiak
естьОн точно математик © Дал абсолютно верный и абсолютно бесполезный ответ.
Sergii Voloshyn
Нечего задавать закрытые вопросы :)
Darya Nazarkina
Я не разработчик, но могу помочить с организацией какого-нибудь ивента(:
Мне эта тема интересна.
Если, что видела вакансии в Одессе — т.е. разработчики там есть.
flyman
idOne Арбузный
«когда в руках молоток, все похоже на гвоздь»
когда в руках молоток, все похоже на гвоздь
предлагаю создать сообщество, собираться периодически, обмениваться опытом, идеями по Go.гвозди шалёвочные есть?
Darya Nazarkina
Есть идея сделать небольшую уютную конфу по такой вот маргинальщине (Go, Erlang, Lua т.д. — то, что встречается довольно редко, но тем не менее существует в коммерческой разработке). Поискать людей с коммерческий проектах — чтобы они рассказали как их занесло и что из этого вышло. Ну и познакомится — пообщаться с сочувствующими(:
Cat Green
Lua бачив не раз, так що напевно не дуже вона і маргінальна. Можна до списку докинути D.
anonymous
луа часто используется в разработке игр — не редкий гость, любителям хомячка сочувствую.
более того, Lua — это флагман геймдева
имхо, перечисленные языки между собой слабо пересекаются.
Лучше найти плоскость где они пересекаются и/или взаимодействуют.
Eugene Nuribekov
Ruslan Kovalov
не розумію, чому Go — це „маргінальніще” :)
docker, kubernetes, terraform, influxdb, cockroachdb, etcd, consul... etc.
minodvesP Vasya
Есть идея сделать небольшую уютную конфу по такой вот маргинальщине (Go, Erlang, Lua
идея интересная. но:
1. Упомянутые языки не настолько маргинальщина, как можно подумать)
2. Если по маргинальщине, то тогда уже что-то типа D, Idris, Nim, Scheme. Хоть они между собой корелируются примерно также как Go с Lua и Эрлангом, но согласитесь, что они более маргинальны. :)
3. А где эта конфа будет проходить (в каком городе)? (если такую конфу можно провести в Одессе — я бы пошел :-) ).
78 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів