Конфигурирование привязки для производительности

Question

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

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

$ 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) 

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

$ 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 МБ.

Вопросы у меня есть:

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

---

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

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

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