.NET Fest: полная программа конференции на сайте. Присоединяйся к самому большому .NET ивенту
×Закрыть

А есть кто интересуется разработкой на Go?

Привет коллеги, предлагаю создать сообщество, собираться периодически, обмениваться опытом, идеями по Go.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

А що можна написати на go (навчальний проект)?

Кому актуально набираємо GoLang Trainee в Харкові. Всі деталі в LinkedIn або Skype: live:burenok_3

Нам нужен Go Full Stack разработчик.

Стек: Go / ReactJS / JS

Мы развиваем продукт под названием RetargetApp — приложение для e-commerce платформ (Shopify, BigCommerce) и т.д. Наше приложение помогает владельцам интернет-магазинов автоматизировать создание и повышать эффективность ретаргетинговых кампаний в Facebook и Instagram

Детальнее: jobs.dou.ua/…​argetapp/vacancies/33180

Мы сейчас ищем к себе Golang программиста для работы над Demand Side Platform. Если интересно — свяжитесь со мной через linkedin или через DOU.

gravity4.com/product

Використовується на проекті. Чуток бавлюсь з Го в домашніх умовах

писав на пітоні і рубі, сішка якось не йшла — але от го йде по повній , втягує потроху.
Єдине , що незвичне так це — ерор хендлінг , а так суперська річ

Очень крутой язык, недавно пытался штурмовать книгу, ну знаете, такая с оленем, времени пока не хватило на полное осиляторство, но общий концепт и работы Фиори ( github.com/fiorix ) впечатляют — парень переписал freegeoip.net c python/twisted на Go и ничего не боится.

Я интересуюсь и даже пишу кое-что на 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.

Точно быстрее тюнингованого nginxа?

Я не спец в тюнинге 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

Выводы делайте сами.

Синтетика это конечно круто, но получить отрыв в 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:                 0
    
    go-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:                 0
    
    go-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% высоконагруженных сайтов, которым мало одного мемкеш-сервера :)
Не понимаю.
Это заметно (
Впрочем можете попробовать убедить Вконтактик потестить ваше поделие. Узнаете много нового. В частности какой характер бывает у реальной нагрузки.

Про характер реальной нагрузки у меня есть интересная статья, в которой почему-то поехало форматирование. Когда я ее писал, с форматированием было все ок.

Опыт важнее статей. В статье лишь часть важного. Да и статья не слишком удачна, извините.

Главная проблема в том, что поток тестовых запросов не является Пуассоновским процессом
Да, это главная проблема статьи) — проблема того, что реальная нагрузка также далека от Пуассоновских потоков — вы упустили основное, реальная нагрузка может быть совершенно неоднородна.
Пуассо́на пото́к (проце́сс) — ординарный поток однородных событий

Выдержка из статьи на википедии про пуассоновский процесс:

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.
Ну и твой Г-код поддерживать врагу не посоветуешь.
  1. Разместите, пожалуйста, ссылку на мой говнокод с обоснованием, почему вы считаете это говнокодом.
  2. Сравните мой говнокод с кодом memcached или всеми любимой "супер"-программы ab
  3. Приведите ссылки на ваш не-говнокод

Иначе кто-то из нас пиздобол :)

Ты смешной такой, у тебя там 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)
	}

Наверное для вызова функции/метода тратится АЖ ОДИН дополнительный такт процессора, а копипаста спасает от этого :-)

Если бы, все эти копипасты таки завернуты в отдельные функции

Тогда виноват, ошибся.
А что тогда бенчмарк показывает когда демонстирует почти 3-кратное превосходство по сравнению с nginx ?

Я хочу сам как нибудь на досуге поиграться с его бенчмарком, тогда и посмотрим.
Но вообще мемкешед слегка сложнее штуковина чем его кеш, оно например поддерживат 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, так что да, твое сравнение становится еще более некоректным.

Перечитайте пожалуйста внимательно мой комент.

Желаю успеха в продвижении и попадании на продакшн реальных больших проектов.
Однако для этого стоит учитывать не только собственных критерии оценки.

Чем этот выкидыш гугла лучше скалы?

компилится заметно быстрее:)

Я весь проект перекомпиливаю максимум раз в день, а ты любишь компилить целыми днями?
Что еще?

у go талисман няшный

Я бы предпочел секси подругу а не хорька. Хотя каждому свое, на вкус и цвет..

а секси-подруга предпочтёт хорька, так что go — вне конкуренции.

отсутвием нормльной поддержки зависимостей лол

Временем старта (если бы я писал какую-то консольную тулзу, тот же мавен, я бы предпочел бы не-jvm язык, про nailgun в курсе), меньшим количеством концепций языка.

Временем старта (если бы я писал какую-то консольную тулзу, тот же мавен, я бы предпочел бы не-jvm язык, про nailgun в курсе)
Ну да, где то там и есть ниша го, толкаться с питоном и руби в области консольных тулзей на 50 строк кода.
меньшим количеством концепций языка.
Мне это вообще понравилось, эти извращенцы выкинули ексепшны и дженерики, как без них жить?

Вам туда, где скала лучше : dou.ua/forums/topic/16012

есть
Он точно математик © Дал абсолютно верный и абсолютно бесполезный ответ.

Нечего задавать закрытые вопросы :)

Я не разработчик, но могу помочить с организацией какого-нибудь ивента(:
Мне эта тема интересна.
Если, что видела вакансии в Одессе — т.е. разработчики там есть.

я пробував хелло ворд? а що далі?

«когда в руках молоток, все похоже на гвоздь»

когда в руках молоток, все похоже на гвоздь
предлагаю создать сообщество, собираться периодически, обмениваться опытом, идеями по Go.
гвозди шалёвочные есть?

Есть идея сделать небольшую уютную конфу по такой вот маргинальщине (Go, Erlang, Lua т.д. — то, что встречается довольно редко, но тем не менее существует в коммерческой разработке). Поискать людей с коммерческий проектах — чтобы они рассказали как их занесло и что из этого вышло. Ну и познакомится — пообщаться с сочувствующими(:

Lua бачив не раз, так що напевно не дуже вона і маргінальна. Можна до списку докинути D.

луа часто используется в разработке игр — не редкий гость, любителям хомячка сочувствую.

более того, Lua — это флагман геймдева

имхо, перечисленные языки между собой слабо пересекаются.
Лучше найти плоскость где они пересекаются и/или взаимодействуют.

не розумію, чому Go — це „маргінальніще” :)
docker, kubernetes, terraform, influxdb, cockroachdb, etcd, consul... etc.

Есть идея сделать небольшую уютную конфу по такой вот маргинальщине (Go, Erlang, Lua

идея интересная. но:
1. Упомянутые языки не настолько маргинальщина, как можно подумать)
2. Если по маргинальщине, то тогда уже что-то типа D, Idris, Nim, Scheme. Хоть они между собой корелируются примерно также как Go с Lua и Эрлангом, но согласитесь, что они более маргинальны. :)
3. А где эта конфа будет проходить (в каком городе)? (если такую конфу можно провести в Одессе — я бы пошел :-) ).

Подписаться на комментарии