История изменений

Пытался отвечать по абзацам, но получается слишком длинно, поэтому просто приведу ряд существенных фактов.

1) Виртуалки (а особенно - виртуалки, запущеные абы как с помощью десктопного софта) могут искажать подсчёты времени и вообще плохо влиять на ситуацию, в том числе неадекватные проценты в логах пхп скорее всего из-за них.

2) Связать интересующее тебя «количество пользователей» и объективное «количество запросов в секунду» без детального анализа устройства и способа использования конкретного сайта невозможно, поэтому про «количество пользователей» пока что придётся забыть; аналогия из реального мира: допустим, тебе поставили задачу спроектировать, какого размера (в сантиметрах) и сколько электричества в сутки должен потреблять технический прибор на 5 человек, но не уточнили: это холодильник, телевизор, стиральная машина или микроавтобус. Очевидно, в таких условиях ты ничего сказать не сможешь.

3) Если тестируешь выдерживание нагрузки на сайт, то главным итогом работы будет количество обработанных запросов в секунду. ab его выдаёт в своём отчёте. Соответственно, он сравнивается с тем, что ты хочешь (меньше или больше) и узнаёшь, хватает этого железа или нет.

4) Надо учитывать, что нагрузка, которую создаёт ab, это совсем не то же самое что нагрузка, создаваемая реальными пользователями, и чем сложнее устроен сайт, тем больше между ними расхождение. Для сложных сайтов флуд запросами на один и тот же адрес малопоказателен. Да, теоретически можно просчитать заранее профиль запросов к сайту и всё спроектировать, но на практике это нецелесообразно - затраты на эту возню будут больше чем просто купить железо с большим запасом, не устраивая точных подгонок. Кроме того, этот запас будет в любом случае полезен на случай неожиданных ситуаций.

5) В твоём запуске ab было настроено -c 1000 - это 1000 параллельных запросов. При этом процессорных потоков у тебя явно меньше, реально работать будет не больше чем количество потоков, остальные будут ждать - либо в очереди процессов на процовое время, либо в очереди tcp-соединений, либо ещё где-то. Где именно будут ждать - зависит от настроек веб-сервера, пхп и скриптов сайта. «Ждать в очереди на проц» - самый плохой вариант, и чтобы его не случалось, у пхп есть настройка pm.max_children, куда надо прописать адекватное ограничение (для простых скриптов типа phpinfo это меньше чем количество процовых ядер, умноженных на 1.5 если есть гипертрединг, а для сложных сайтов отдельная история т.к. там скрипт не всегда занимает проц). Ставить -c заметно больше чем max_children смысла нет, это будет только искажать результаты.

Пытался отвечать по абзацам, но получается слишком длинно, поэтому просто приведу ряд существенных фактов.

1) Виртуалки (а особенно - виртуалки, запущеные абы как с помощью десктопного софта) могут искажать подсчёты времени и вообще плохо влиять на ситуацию, в том числе неадекватные проценты в логах пхп скорее всего из-за них.

2) Связать интересующее тебя «количество пользователей» и объективное «количество запросов в секунду» без детального анализа устройства и способа использования конкретного сайта невозможно, поэтому про «количество пользователей» пока что придётся забыть; аналогия из реального мира: допустим, тебе поставили задачу спроектировать, какого размера (в сантиметрах) и сколько электричества в сутки должен потреблять технический прибор на 5 человек, но не уточнили: это холодильник, телевизор, стиральная машина или микроавтобус. Очевидно, в таких условиях ты ничего сказать не сможешь.

3) Если тестируешь выдерживание нагрузки на сайт, то главным итогом работы будет количество обработанных запросов в секунду. ab его выдаёт в своём отчёте. Соответственно, он сравнивается с тем, что ты хочешь (меньше или больше) и узнаёшь, хватает этого железа или нет.

4) Надо учитывать, что нагрузка, которую создаёт ab, это совсем не то же самое что нагрузка, создаваемая реальными пользователями, и чем сложнее устроен сайт, тем больше между ними расхождение. Для сложных сайтов флуд запросами на один и тот же адрес малопоказателен. Да, теоретически можно просчитать заранее профиль запросов к сайту и всё спроектировать, но на практике это нецелесообразно - затраты на эту возню будут больше чем просто купить железо с большим запасом, не устраивая точных подгонок. Кроме того, этот запас будет в любом случае полезен на случай неожиданных ситуаций.

5) В твоём запуске ab было настроено -c 1000 - это 1000 параллельных запросов. При этом процессорных потоков у тебя явно меньше, реально работать будет не больше чем количество потоков, остальные будут ждать - либо в очереди процессов на процовое время, либо в очереди tcp-соединений, либо ещё где-то. Где именно будут ждать - зависит от настроек веб-сервера, пхп и скриптов сайта. «Ждать в очереди на проц» - самый плохой вариант, и чтобы его не случалось, у пхп есть настройка pm.max_children, куда надо прописать адекватное ограничение (для простых скриптов типа phpinfo это меньше чем количество процовых ядер, умноженных на 1.5 если есть гипертрединг, а для сложных сайтов отдельная история т.к. там скрипт не всегда занимает проц).

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

1) Виртуалки (а особенно - виртуалки, запущеные абы как с помощью десктопного софта) могут искажать подсчёты времени и вообще плохо влиять на ситуацию, в том числе неадекватные проценты в логах пхп скорее всего из-за них.

2) Связать интересующее тебя «количество пользователей» и объективное «количество запросов в секунду» без детального анализа устройства и способа использования конкретного сайта невозможно, поэтому про «количество пользователей» пока что придётся забыть; аналогия из реального мира: допустим, тебе поставили задачу спроектировать, какого размера (в сантиметрах) и сколько электричества в сутки должен потреблять технический прибор на 5 человек, но не уточнили: это холодильник, телевизор, стиральная машина или микроавтобус. Очевидно, в таких условиях ты ничего сказать не сможешь.

3) Если тестируешь выдерживание нагрузки на сайт, то главным итогом работы будет количество обработанных запросов в секунду. ab его выдаёт в своём отчёте. Соответственно, он сравнивается с тем, что ты хочешь (меньше или больше) и узнаёшь, хватает этого железа или нет.

4) Надо учитывать, что нагрузка, которую создаёт ab, это совсем не то же самое что нагрузка, создаваемая реальными пользователями, и чем сложнее устроен сайт, тем больше между ними расхождение. Для сложных сайтов флуд запросами на один и тот же адрес малопоказателен. Да, теоретически можно просчитать заранее профиль запросов к сайту и всё спроектировать, но на практике это нецелесообразно - затраты на эту возню будут больше чем просто купить железо с большим запасом, не устраивая точных подгонок. Кроме того, этот запас будет в любом случае полезен на случай неожиданных ситуаций.

5) В твоём запуске ab было настроено -c 1000 - это 1000 параллельных запросов. При этом процессорных потоков у тебя явно меньше, реально работать будет не больше чем количество потоков, остальные будут ждать - либо в очереди процессов на процовое время, либо в очереди tcp-соединений, либо ещё где-то. Где именно будут ждать - зависит от настроек веб-сервера, пхп и скриптов сайта. «Ждать в очереди на проц» - самый плохой вариант, и чтобы его не случалось, у пхп есть настройка pm.max_children, куда надо прописать адекватное ограничение (для простых скриптов типа phpinfo это меньше чем количество процовых ядер, умноженных на 1.5 если есть гипертрединг, а для сложных сайтов отдельная история т.к. там скрипт не всегда занимает проц).