Как стать автором
Обновить

Комментарии 9

Выбор ос по мне странен.
поддержу
кроме того, для разработки и доведения до ума можно было и локально гонять, но с финальными тестами неплохо было бы заморочиться и прогнать в облаке, разделив бд, сервис и тест по трем инстансам.
У потенциального заказчика используется платформа Windows.

нужно больше тестов, хороших и разных, чтобы можно было строить всяческие аппроксимации

В тесте очень много проблем, которые не составляет большого труда починить, и вот основные:


  1. Описание стенда недостаточно: слова «Core i7 4/8 cores/threads» покрывают кучу процессоров (включая ноутбучные), выпускавшихся в течение последних 10 лет. То же про диск HDD/SSD: это один гибридный накопитель или несколько разных? Если разные, то на каком располагалась БД? Значительно лучше идентифицировать компоненты стенда полностью, чтобы читатель не гадал (например, диски бывают 5400 RPM и 15000 RPM, и разница для БД значительная, хоть они и оба HDD);


  2. Неясно, каков размер БД в PostgreSQL. Лично видел людей, которые тестировали влияние жестких дисков на модельной БД, целиком влезающей в память дважды, и не чистили память между тестами. Модельная БД «весила» 2 гигабайта, а проектная боевая — 200 гигабайт. В таких условиях в результаты теста можно даже не смотреть;


  3. Расположение нагружающего элемента на той же железке ведёт к разнообразным спецэффектам, которые, вообще говоря, не могут быть строго объяснены: в том же случае с ab неясно, это нагружатель не смог нагрузить и вынудил приложение работать с «длинными» подключениями, или же приложение не смогло качественно отвечать, потому что нагружатель занял CPU (кстати, чем?). Поэтому нагружатель нужно выносить на другую железку, и ещё неплохо бы использовать несколько разных время от времени, поскольку у нагружателей тоже бывают проблемы.



В целом бирки клеить нужно. Но аккуратно.

Добавил в статью описание характеристики процессора, HDD и SSD, размер БД, а так же результаты тестов на HDD.
Ab не стал выносить на отдельную машину — чтобы не учитывать сетевые задержки.
Нуу, сколько там задержек, половина миллисекунды, если второй компьютер в том же здании и в не шибко занятой сети? Плюс 55 тысяч пакетов по полтора килобайта, это 3/4 гигабитного линка по пропускной способности, ±. И в итоге всё равно непонятно, сколько стенд выдаст сам, а не с висящим на нём же нагружатором (держать базу и кэш на той же железке, впрочем, законно: не у всех эти 55 тысяч запросов вообще случатся когда-нибудь, чтобы их разделять). Тестировать в облаках отличный план, потому что дёшево (поднял стенд, прогнал тест, удалил стенд, заплатил 50 центов), и для повторения Ваших результатов кому-то ещё совершенно не нужно искать в точности такой же процессор.
Добавил профилирование

nginx на одном ядре без особой настройки с включённым кэшированием способен обрабатывать 50.000+ запросов в секунду. В чём смысл городить огород на бэкенде?

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории