Никто не спорит, есть вероятность, что 24 человека в одну секунду решат сайт открыть и он у них будет открываться в разы медленнее, но это маловероятное событие. Если таких "медленных" запросов будет меньше 1%, то ими скорее можно пренебречь. Медианное же значение в те секунды, когда нагрузка есть, скорее всего в районе 1-2 RPS.
Здесь еще вопрос, не попала ли статика в эти "до 24 RPS", если попала, то 24 можно поделить в 3-6 раз за счет статики, которая ядро Drupal не дергает.

Ну я и учел, что не размазана ровно по суткам и умножил не на 24 часа, а на 10 -)

Касательно пиков: тогда лучше на примерах. Вот на drupal.ru по similarweb в январе было 90k визитов. Сколько в секунду пиковая нагрузка максимальная была и как это измерялось?

Для сравнения. Да.
Соглашусь, заголовок поста в этом смысле не очень удачен. Но с другой стороны все эти попугаи в каких-нибудь GeekBench или tps в pgbench или даже iops в fio разве тоже не для сравнения?

Вообще ab имеет смысл и с -с 1:

Все верно.

Если вам нужно производительность сайта (а не сервера под запуск сферического Drupal в вакууме), причем конкретного сайта со 100500 развернутыми модулями, блоками и т.д. - JMeter и вперед. Инфы по JMeter достаточно.

В варианте ls /etc вы измеряете производительность переключения контекста и скорость листинга файлов в файловой системе, согласитесь, совсем не тоже самое, что инициализировать ядро Drupal -)

Теперь по универсальным бенчмаркам.

Вот вы измерили fio скорость дисков. Увидели, что на 4k рандомом такая производительность, на 1M последовательно сякая. Дальше что? Вам же сервер нужен не для бенчмарков, а чтобы Drupal на нем гонять. Значит надо как-то эти цифры к Drupal подбить.

Все верно, это про одноядерную производительность, так и написал в ограничениях -)

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

ab тоже неплохой вариант по быстрому проверить, но ab не умеет сохранение проверять, только чтение.

Хочу только обратить внимание, что тест затрагивал крайне простой случай, когда запрос повторяется на одну и ту же страницу с минимумом логики и запросов в базу. Т.е. все берется из прогретого кеша.

В реальных рабочих нагрузках все может быть не так здорово.

bsyomov wrote:

Оно так, но далеко не всегда это даёт возможность процессору получить данные в 10 раз быстрее, даже если они в кеше. Так что даже если бы вся память, предположим, помещалась бы в этот кеш, и задача была бы перемешивать данные в памяти, то всё равно был бы прирост заметно меньше 10 раз. А задачи, всё же, обычно больше вычислительные.

Дак прирост и меньше 10 раз. 3-4 раза.

Чтобы было примерное понимание, почему кеш многое объясняет:

Задержки обращения процессора в L3 примерно в 10 раз меньше задержек обращения в ОЗУ.

Отсюда и может вылазить ускорение в разы.

bsyomov wrote:

Вообще, чтобы тестировать такие вещи и делать подобные выводы, должен быть собран стенд, с одной и той же памятью на одной частоте, желательно, процессорами на одной частоте, с одной и той же периферией всей, и одним и тем же ПО. И вот тогда можно говорить о влиянии размера кеша. А тут могло быть причиной вообще что угодно. Более быстрая память, другая процессорная архитектура, даже настройки постгреса.

Здесь да, много предположений. Может всё несколько не так, для этого неплохо бы попробовать поискать ситуации, когда у кого-то тоже ускорение в 3-4 раза и посмотреть в чем различия.

Но давайте вспомним, что в PHP включен opcache. Т.е. байткод Drupal при повторном обращении к странице уже скомпилирован и находится в ОЗУ.

Сам движок PHP тоже где-то в ОЗУ сидит.

То, что дело в кеше - гипотеза. Если у кого-то есть Xeon c 32 или 64 МБ кеша L3 - прошу проверить и написать результаты. У меня такого камня нет.

jura12 wrote:

я старым интел процессором не доверяю. обещали падение производительности до 30% изза патчей от уязвимостей Spectre и Meltdown. а процессор rysen 3600 новый. при техже частотах должен работать быстрее. кэш конечно важен но надо высчитывать производительность на ядро или на частоту.

cat /proc/cpuinfo

bsyomov wrote:

На самом деле, надо просто один раз зайти в аккаунт почты через интерфейс яндекса и завершить его регистрацию. Тогда будет работать почта без паролей приложений.

Может раньше так и было, а нынче у меня оно не вышло.

В GMail тоже надо отправку через "приложения" подключать, там-то прямо сообщения приходят, что отправка письма заблокирована.