Comments 9
нужно больше тестов, хороших и разных, чтобы можно было строить всяческие аппроксимации
В тесте очень много проблем, которые не составляет большого труда починить, и вот основные:
Описание стенда недостаточно: слова «Core i7 4/8 cores/threads» покрывают кучу процессоров (включая ноутбучные), выпускавшихся в течение последних 10 лет. То же про диск HDD/SSD: это один гибридный накопитель или несколько разных? Если разные, то на каком располагалась БД? Значительно лучше идентифицировать компоненты стенда полностью, чтобы читатель не гадал (например, диски бывают 5400 RPM и 15000 RPM, и разница для БД значительная, хоть они и оба HDD);
Неясно, каков размер БД в PostgreSQL. Лично видел людей, которые тестировали влияние жестких дисков на модельной БД, целиком влезающей в память дважды, и не чистили память между тестами. Модельная БД «весила» 2 гигабайта, а проектная боевая — 200 гигабайт. В таких условиях в результаты теста можно даже не смотреть;
Расположение нагружающего элемента на той же железке ведёт к разнообразным спецэффектам, которые, вообще говоря, не могут быть строго объяснены: в том же случае с ab неясно, это нагружатель не смог нагрузить и вынудил приложение работать с «длинными» подключениями, или же приложение не смогло качественно отвечать, потому что нагружатель занял CPU (кстати, чем?). Поэтому нагружатель нужно выносить на другую железку, и ещё неплохо бы использовать несколько разных время от времени, поскольку у нагружателей тоже бывают проблемы.
В целом бирки клеить нужно. Но аккуратно.
Ab не стал выносить на отдельную машину — чтобы не учитывать сетевые задержки.
nginx на одном ядре без особой настройки с включённым кэшированием способен обрабатывать 50.000+ запросов в секунду. В чём смысл городить огород на бэкенде?
UPD. Тестирование REST API на Golang. 120 000 [#/sec] не предел?