Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 23
Кажется лежим… а так интересно было что там
curl -v http://ugly.begetan.me/
* Trying 138.201.246.68...
* TCP_NODELAY set
* Connected to ugly.begetan.me (138.201.246.68) port 80 (#0)
> GET / HTTP/1.1
> Host: ugly.begetan.me
> User-Agent: curl/7.51.0
> Accept: */*
>
< HTTP/1.1 500 Internal Server Error
< Server: nginx
< Date: Tue, 21 Feb 2017 07:11:13 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
<
* Curl_http_done: called premature == 0
* Connection #0 to host ugly.begetan.me left intact
>> Когда я увеличивал количество параллельных запросов wrk, то увеличивалось процессорное время потребляемое nginx-ом. Из-за этого не хватало ресурсов для php-fpm и в логах возникали ошибки 499 и 502. В этом месте было бы правильным переписать приложение, заменив Тарантул на какую-нибудь обычную SQL базу данных – MySQL или PostgreSQL и сравнить результаты.
Да, хорошо бы сравнить с Mysql InnoDB и TokuDB в Percona. Но этот абзац я не понимаю, ошибки возникают в php-fpm, а предложение о замене базы.
Да, хорошо бы сравнить с Mysql InnoDB и TokuDB в Percona. Но этот абзац я не понимаю, ошибки возникают в php-fpm, а предложение о замене базы.
Замена базы нужна, что бы показать разницу производительности между Тарантулом и MySQL, например. Но мы понимаем же, что ожидается заведомый регресс.
Я бы поступил наоборот — переписал бы какое то приложение с MySQL на Тарантул.
Про ошибки nginx относилось к первой части статьи о методике тестирования.
Я бы поступил наоборот — переписал бы какое то приложение с MySQL на Тарантул.
Про ошибки nginx относилось к первой части статьи о методике тестирования.
Не прицепиться ради, но вот:
Можно уточнить, где у вас в отчете rps?
Я решил немного проверить и по возможности дополнить ваше измерение своим тестом. Обычно в таких случаях мне всегда нравится постепенное увеличение нагрузки с целью понять предел системы и определить то, за чем нужно следить во время выкатывания нового релиза.
Надеюсь вы меня не будете строго судить, потому как я лишь любитель :)
Суть моего теста состояла в том, чтобы увеличивать количество параллельных пользователей попеременно опрашивающих четыре страницы с сервера (без всяких там голосований и пр… можно конечно и такой тест написать, но я не хочу флудить в базу). Наличие т.н. Think Time я решил опустить, потому что любая пауза в действиях пользователя снижает одновременное количество запросов, которые сервер вынужден обработать. Это всё равно что — «мы обслуживаем сто миллионов пользователей в день, где каждый пользователь в среднем открывает одну страницу в сутки». В таких выражениях важно знать некоторую конкурентность пользователей (среднюю, минимальную, максимальную) и время ответа.
В моей любительской теории я просто оцениваю параллельные запросы, которые потом можно наблюдать в проекте и уже решать помогло ли нам увеличение числа ядер/серверов/бутылок_пива_в_админке или нет.
Самым важным параметром, на который я опирался — это количество т.н. транзакций в единицу времени. То есть сколько запросов может обслужить сервер если параллельное число запросов равно N:
Что можно отсюда сказать? Каждый новый пользователь повышает нашу пропускную способность, пока дальнейший рост нагрузки перестаёт влиять на это значение. Другими словами, не важно сколько пользователей будет долбиться на сервер, денег вы больше не заработаете… я хотел сказать, больше вы не обслужите — у ваших пользователей будет расти время ожидания:
Как вы видите по графику «предел прочности» составил где-то 20 параллельных пользователей. Дальнейшее увеличение нагрузки ни к чему хорошему не привело. В определённый момент времени сервер сломался и начал отказывать мне в доступе — соответственно на 70 потоках я стал очень быстро получать ошибки, отсюда выросла пропускная способность (уж что что, а сервер отдаёт ошибки очень быстро :) ).
Всё, надеюсь вы сочли мой комментарий, написанный на коленке, полезным. Извините, за ошибки.
Ах да, предвосхищу чужие вопросы — нагружал тачкой в 36 ядер, которая была у меня под рукой.
Надеюсь вы меня не будете строго судить, потому как я лишь любитель :)
Суть моего теста состояла в том, чтобы увеличивать количество параллельных пользователей попеременно опрашивающих четыре страницы с сервера (без всяких там голосований и пр… можно конечно и такой тест написать, но я не хочу флудить в базу). Наличие т.н. Think Time я решил опустить, потому что любая пауза в действиях пользователя снижает одновременное количество запросов, которые сервер вынужден обработать. Это всё равно что — «мы обслуживаем сто миллионов пользователей в день, где каждый пользователь в среднем открывает одну страницу в сутки». В таких выражениях важно знать некоторую конкурентность пользователей (среднюю, минимальную, максимальную) и время ответа.
В моей любительской теории я просто оцениваю параллельные запросы, которые потом можно наблюдать в проекте и уже решать помогло ли нам увеличение числа ядер/серверов/бутылок_пива_в_админке или нет.
Самым важным параметром, на который я опирался — это количество т.н. транзакций в единицу времени. То есть сколько запросов может обслужить сервер если параллельное число запросов равно N:
Transactions vs Threads
Что можно отсюда сказать? Каждый новый пользователь повышает нашу пропускную способность, пока дальнейший рост нагрузки перестаёт влиять на это значение. Другими словами, не важно сколько пользователей будет долбиться на сервер, денег вы больше не заработаете… я хотел сказать, больше вы не обслужите — у ваших пользователей будет расти время ожидания:
что мы и наблюдаем...
Как вы видите по графику «предел прочности» составил где-то 20 параллельных пользователей. Дальнейшее увеличение нагрузки ни к чему хорошему не привело. В определённый момент времени сервер сломался и начал отказывать мне в доступе — соответственно на 70 потоках я стал очень быстро получать ошибки, отсюда выросла пропускная способность (уж что что, а сервер отдаёт ошибки очень быстро :) ).
Всё, надеюсь вы сочли мой комментарий, написанный на коленке, полезным. Извините, за ошибки.
Ах да, предвосхищу чужие вопросы — нагружал тачкой в 36 ядер, которая была у меня под рукой.
Интересный график, но было бы намного интереснее делать их с отключенной директивой limit_conn 64 в настройках nginx. Мои тесты выполнялись с отключенными ограничениями, естественно.
Я думаю, что от 20 до 70 потоков работал лимит соединений, а после 70 видимо достаточно сильно выросла нагрузка на nginx и он подавил остальные процессы.
Про рост времени ожидания вы просто еще раз подтвердили выводы из статьи Константина Осипова, ссылка на которую есть наверху.
Я думаю, что от 20 до 70 потоков работал лимит соединений, а после 70 видимо достаточно сильно выросла нагрузка на nginx и он подавил остальные процессы.
Про рост времени ожидания вы просто еще раз подтвердили выводы из статьи Константина Осипова, ссылка на которую есть наверху.
Объясните мне, пожалуйста — неужели практически для всех веб-сайтов база нужна исключительно для хранения key-value?
Слышу везде про NoSQL. Сложные структуры данных, получается, не нужны? связи там…
Слышу везде про NoSQL. Сложные структуры данных, получается, не нужны? связи там…
Рейтинги или сессии пользователей достаточно распространенная задача для K/V хранилища.
Сложные связи конечно нужны, но допустим, одна из задач микросервисной архитектуры состоит в упрощении или переносе этой сложности из базы данных на уровень связи компонентов.
Сложные связи конечно нужны, но допустим, одна из задач микросервисной архитектуры состоит в упрощении или переносе этой сложности из базы данных на уровень связи компонентов.
… а потом с болью и кровью имплементировать «ACID между компонентами». Заодно узнать про eventual consitency. По ходу дела научиться правильно инвалидировать кеши. А затем удивиться перфомансу.
PS Я не к тому что микросервисы или NoSQL — это плохо. Это просто инструмент которым надо аккуратно пользоваться, понимая что для забивания гвоздей лучше походит молоток чем отвертка.
PPS Раз уж сравнили тарантул с mysql, поинтересуюсь: а тарантул обеспечивает ACID и декларативный язык запросов сравнимый с SQL?
PS Я не к тому что микросервисы или NoSQL — это плохо. Это просто инструмент которым надо аккуратно пользоваться, понимая что для забивания гвоздей лучше походит молоток чем отвертка.
PPS Раз уж сравнили тарантул с mysql, поинтересуюсь: а тарантул обеспечивает ACID и декларативный язык запросов сравнимый с SQL?
Тарантул это молоток и есть. Для SQL есть свои отвертки с хитрой резьбой.
Только приглядитесь к логотипу!
Только приглядитесь к логотипу!
Ответы на ваши вопросы есть прямо на первой странице tarantool.org in large friendly letters:
да.
Да. Тарантул вообще декларируется не как NoSQL хранилище данных, NoSQL это скорей побочная черта архитектуры, а вообще это сервер приложений LUA. LUA в том числе можно использовать в декларативном стиле, но совсем не обязательно, т.к. это гораздо более удобный и гибкий язык, чем TSQL или PL/SQL. А поддержка SQL в анонсирована в разрабатываемых версиях Tarantool.
а тарантул обеспечивает ACID
да.
декларативный язык запросов сравнимый с SQL
Да. Тарантул вообще декларируется не как NoSQL хранилище данных, NoSQL это скорей побочная черта архитектуры, а вообще это сервер приложений LUA. LUA в том числе можно использовать в декларативном стиле, но совсем не обязательно, т.к. это гораздо более удобный и гибкий язык, чем TSQL или PL/SQL. А поддержка SQL в анонсирована в разрабатываемых версиях Tarantool.
Почитал доку.
Транзакции: уровней изоляции не нашел, только оптимистические блокировки.
Судя по ответу ниже, SQL в процессе.
Я правильно понимаю, что в отличии от многих NoSQL решений, tarantool не обеспечивает «из коробки» инструментов построения отказоустойчивого распределенного кластера, как то шардирования, синхронизации после сетевого разделения? Репликация не в счет.
Транзакции: уровней изоляции не нашел, только оптимистические блокировки.
Судя по ответу ниже, SQL в процессе.
Я правильно понимаю, что в отличии от многих NoSQL решений, tarantool не обеспечивает «из коробки» инструментов построения отказоустойчивого распределенного кластера, как то шардирования, синхронизации после сетевого разделения? Репликация не в счет.
Про Транзакции почитайте тут: http://kostja.github.io/misc/2017/01/24/tarantool-design-principles.html и тут: https://tarantool.org/doc/book/box/atomic.html
По поводу второго вашего вопроса — правильно понимаете. Но скорее всего у вас нет и не будет таких нагрузок, чтобы одна машина с Тарантулом не справилась. Даже у мейла редко бывают такие нагрузки — и мы ставим 4 машины, шардим на уровне приложения и это работает на долгие годы впероед.
По поводу второго вашего вопроса — правильно понимаете. Но скорее всего у вас нет и не будет таких нагрузок, чтобы одна машина с Тарантулом не справилась. Даже у мейла редко бывают такие нагрузки — и мы ставим 4 машины, шардим на уровне приложения и это работает на долгие годы впероед.
ACID обеспечивает. SQL в процессе. Если интересен недекларативный язык запросов, то это Lua, работает в виде хранимых процедур внутри Tarantool.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Tarantool: нагрузочное тестирование