Настройка Snap для производительности

Я просто играю с фреймворком Snap и хотел посмотреть, как он работает по сравнению с другими фреймворками (при полностью искусственных обстоятельствах).

Что я обнаружил, так это то, что мое приложение Snap достигает максимума примерно в 1500 запросов в секунду (приложение просто snap init; snap build; ./dist/app/app, т.е. код не изменяется в приложении по умолчанию, созданном Snap):

$ ab -n 20000 -c 500 http://127.0.0.1:8000/                                        
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Completed 20000 requests
Finished 20000 requests


Server Software:        Snap/0.9.5.1
Server Hostname:        127.0.0.1
Server Port:            8000

Document Path:          /
Document Length:        721 bytes

Concurrency Level:      500
Time taken for tests:   12.845 seconds
Complete requests:      20000
Failed requests:        0
Total transferred:      17140000 bytes
HTML transferred:       14420000 bytes
Requests per second:    1557.00 [#/sec] (mean)
Time per request:       321.131 [ms] (mean)
Time per request:       0.642 [ms] (mean, across all concurrent requests)
Transfer rate:          1303.07 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   44 287.6      0    3010
Processing:     6  274 153.6    317    1802
Waiting:        5  274 153.6    317    1802
Total:         20  318 346.2    317    3511

Percentage of the requests served within a certain time (ms)
  50%    317
  66%    325
  75%    334
  80%    341
  90%    352
  95%    372
  98%   1252
  99%   2770
 100%   3511 (longest request)

Затем я запустил приложение Grails, и кажется, что Tomcat (после прогрева JVM) может взять на себя немного больше нагрузки:

$ ab -n 20000 -c 500 http://127.0.0.1:8080/test-0.1/book                                                                                                                                                                                                     
This is ApacheBench, Version 2.3 <$Revision: 1706008 $>
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking 127.0.0.1 (be patient)
Completed 2000 requests
Completed 4000 requests
Completed 6000 requests
Completed 8000 requests
Completed 10000 requests
Completed 12000 requests
Completed 14000 requests
Completed 16000 requests
Completed 18000 requests
Completed 20000 requests
Finished 20000 requests


Server Software:        Apache-Coyote/1.1
Server Hostname:        127.0.0.1
Server Port:            8080

Document Path:          /test-0.1/book
Document Length:        722 bytes

Concurrency Level:      500
Time taken for tests:   4.366 seconds
Complete requests:      20000
Failed requests:        0
Total transferred:      18700000 bytes
HTML transferred:       14440000 bytes
Requests per second:    4581.15 [#/sec] (mean)
Time per request:       109.143 [ms] (mean)
Time per request:       0.218 [ms] (mean, across all concurrent requests)
Transfer rate:          4182.99 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0   67 347.4      0    3010
Processing:     1   30  31.4     21     374
Waiting:        0   26  24.4     20     346
Total:          1   97 352.5     21    3325

Percentage of the requests served within a certain time (ms)
  50%     21
  66%     28
  75%     35
  80%     42
  90%     84
  95%    230
  98%   1043
  99%   1258
 100%   3325 (longest request)

Я предполагаю, что отчасти это может быть связано с тем, что Tomcat резервирует много оперативной памяти и может хранить/кэшировать некоторые методы. Во время этого эксперимента Tomcat использовал более 700 МБ или ОЗУ, в то время как Snap едва приблизился к 70 МБ.

У меня есть вопросы:

  • Я сравниваю яблоки и апельсины здесь?
  • Какие шаги нужно предпринять, чтобы оптимизировать Snap для пропускной способности/скорости?

Дальнейшие эксперименты:

Затем, как предложил mightybyte, я начал экспериментировать с +RTS -A4M -N4 вариантами. Приложение смогло обслужить чуть более 2000 запросов в секунду (увеличение примерно на 25%).

Я также удалил вложенные шаблоны и предоставил документ (того же размера, что и раньше) из файла tpl верхнего уровня. Это увеличило производительность до чуть более 7000 запросов в секунду. Использование памяти увеличилось примерно до 700 МБ.


haskell haskell-snap-framework
person zoran119    schedule 11.05.2016    source источник

Ответы (2)


arrow_upward
2
arrow_downward

Ответ jkeuhlen дает хорошие наблюдения, относящиеся к вашему первому вопросу. Что касается вашего второго вопроса, определенно есть вещи, с которыми вы можете поиграть, чтобы настроить производительность. Если вы посмотрите на старые необработанные данные результатов Snap, вы можно увидеть, что мы запускали приложение с +RTS -A4M -N4. Параметр -N4 указывает среде выполнения GHC использовать 4 потока. (Обратите внимание, что для этого вам нужно собрать приложение с параметром -threaded.) Параметр -A4M устанавливает размер области размещения сборщика мусора. Наши эксперименты показали, что эти два параметра оказывают наибольшее влияние на производительность. Но это было сделано давным-давно, и с тех пор GHC сильно изменился, поэтому вы, вероятно, захотите поиграть с ними и найти то, что лучше всего подходит для вас. На этой странице содержится подробная информация о другие параметры командной строки, доступные для управления временем выполнения GHC, если вы хотите провести больше экспериментов.

В прошлом году была проделана небольшая работа по обновлению бенчмарков. Если вам это интересно, просмотрите различные ветки в репозитории snap-benchmarks. Было бы здорово получить дополнительную помощь по новому набору тестов.

person mightybyte    schedule 12.05.2016

arrow_upward
4
arrow_downward

Я ни в коем случае не эксперт в этом вопросе, поэтому могу ответить только на ваш первый вопрос, и да, вы сравниваете яблоки и апельсины (а также бананы, не осознавая этого).

Во-первых, похоже, что вы пытаетесь сравнить разные вещи, поэтому, естественно, ваши результаты будут противоречивыми. Одно из них — пример приложения Snap, а другое — просто «приложение Grails». Что именно делает каждая из этих вещей? Вы обслуживаете страницы? Обработка запросов? Разница в приложениях объяснит разницу в производительности.

Во-вторых, разница в использовании оперативной памяти также показывает разницу в том, что делают эти приложения. Веб-фреймворки Haskell очень хорошо справляются с большими экземплярами без большого количества ОЗУ, в то время как другие фреймворки, такие как Tomcat, как вы видели, будут ограничены в своей производительности с ограниченным объемом ОЗУ. Попробуйте ограничить оба приложения до 100 МБ и посмотрите, что произойдет с вашей разницей в производительности.

Если вы хотите сравнить различные фреймворки, вам действительно нужно запустить для этого стандартное приложение. Snap сделал это с помощью теста Pong. Результаты старого теста (от 2011 года и Snap 0.3) можно увидеть здесь. . Этот абзац очень актуален для вашей ситуации:

Если вы сравните это с нашими предыдущими результатами, то заметите, что мы не включили Grails. Мы обнаружили, что наши предыдущие результаты для Grails, возможно, были слишком низкими, потому что JVM не давали времени на прогрев. Проблема в том, что после прогрева JVM по какой-то причине httperf не может получить какие-либо выборки, из которых можно сгенерировать измерение ответов в секунду, поэтому он выводит 0,0 ответов в секунду. Также имеется 1000 ошибок connreset, поэтому мы решили, что цифры Grails недостаточно надежны для использования.

Для сравнения, в блоге Yesod есть тест Pong примерно того же времени, который показывает аналогичные результаты. Вы можете найти это здесь. Они также ссылаются на свой код теста, если вы хотите попробовать запустить более похожий тест, он доступен на Github.

person jkeuhlen    schedule 11.05.2016