Эффективность, Бенчмаркинг, Тестирование скорости, Производительность

Question

Я пытаюсь написать сценарий, эффективность которого я пытаюсь измерить. У меня есть пара вопросов: -

1. Требуется ли такое профилирование для небольших приложений? Или я становлюсь параноиком? (при условии, что большая часть кода является достаточно эффективной / без бесконечных циклов)
2. Против чего мне это делать? С чем сравнивать?
3. Ниже приведен результат эффективности, который я получил из ab. Это слишком далеко? Я иду в неправильном направлении, проектируя это приложение? Есть ли какие-либо предупреждающие сигналы, о которых мне следует знать?

abs -n10000 -c100 http://localhost/testapp

This is ApacheBench, Version 2.3 
Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
Licensed to The Apache Software Foundation, http://www.apache.org/

Benchmarking localhost (be patient)
Completed 1000 requests
Completed 2000 requests
Completed 3000 requests
Completed 4000 requests
Completed 5000 requests
Completed 6000 requests
Completed 7000 requests
Completed 8000 requests
Completed 9000 requests
Completed 10000 requests
Finished 10000 requests


Server Software:        Apache/2.2.10
Server Hostname:        localhost
Server Port:            80

Document Path:          /testapp
Document Length:        525 bytes

Concurrency Level:      100
Time taken for tests:   33.608 seconds
Complete requests:      10000
Failed requests:        5179
   (Connect: 0, Receive: 0, Length: 5179, Exceptions: 0)
Write errors:           0
Total transferred:      6973890 bytes
HTML transferred:       5253890 bytes
Requests per second:    297.55 [#/sec] (mean)
Time per request:       336.080 [ms] (mean)
Time per request:       3.361 [ms] (mean, across all concurrent requests)
Transfer rate:          202.64 [Kbytes/sec] received

Connection Times (ms)
              min  mean[+/-sd] median   max
Connect:        0    1   1.5      0     109
Processing:     8  334 403.9    176    3556
Waiting:        7  334 403.9    176    3556
Total:          9  335 403.8    177    3556

Percentage of the requests served within a certain time (ms)
  50%    177
  66%    296
  75%    415
  80%    519
  90%    842
  95%   1141
  98%   1615
  99%   1966
 100%   3556 (longest request)

Я использую PHP для написания скрипта. При дальнейшем тестировании я также обнаружил, что «Сбой запросов» становится равным 0, если я комментирую часть соединения MySQL из моего PHP-скрипта. В чем дело? Как уменьшить частоту отказов?

Спасибо, Alec

Answer 1

Ожидаете ли вы 100 одновременных запросов? Ожидаете ли вы получить 10 000 запросов в течение 30 секунд?

Здорово, что вы можете запустить этот тест, но спросите себя, что это значит. Подумайте о реальном объеме трафика, который вы будете получать. Вам действительно нужен вопрос для сравнения:

• Я ожидаю, что на моем сайте будет 3000 пользователей.
• Я ожидаю, что во время пиковой нагрузки 500 из них попадут на страницу
• Обычно используется 3 запроса в минуту: 3 * 500 / 60 = ~ 25 req/sec
• Может ли мой сайт обрабатывать 25 запросов в секунду и отвечать на запросы (<200 мс на запрос)? </li>

Если вы не находитесь в верхних нескольких процентах Интернета, на вашей странице не будет 100 одновременных запросов в реальной жизни. Нет смысла настраивать ваш сайт для этого уровня трафика. Чтобы достичь этих цифр, вам нужно идти на компромиссы при проектировании на уровне архитектуры (использование базы данных, методы кэширования и т. Д .: отсюда и количество сбоев при включенной базе данных).

Если вы только пытаетесь профилировать свой скрипт, используйте xdebug , чтобы узнать, на что ваш код тратит свое время.

Answer 2

Попробуйте использовать xdebug для профилирования вашего кода. xdebug также даст вам лучшие ошибки на экране и отслеживание стека.

Затем используйте webgrind для просмотра профиля в хорошем формате.

Answer 3

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

Скорее всего, в MySQL заканчиваются соединения, и в этом случае вы можете просто настроить свой сервер таким образом, чтобы разрешить более параллельные соединения (если вы ожидаете такой объем трафика).

Answer 4

Я думаю, это похоже на отличную работу. Далеко? Я бы сказал, что это намного выше нормы.

Один вопрос - какая нагрузка на сервер будет в производстве. Ваш скрипт запускает запросы на этом сервере, но если вы единственный пользователь в экземпляре разработки, вы не видите, что происходит, когда вы подключаетесь к производственному серверу, пока он обрабатывает типичную производственную нагрузку.

Если это так, вам нужно ДВА источника запросов: один, представляющий ваше новое приложение, а другой - для производственных процессов, с которыми оно будет конкурировать за ресурсы.

Можете ли вы установить количество одновременных пользователей в тестовом программном обеспечении? Этот тест просто отправляет 1000 запросов, один за другим? Несколько пользователей могут стучать по серверу одновременно, может быть более реалистичным.

Можете ли вы сделать интервал отправки случайным? Это могло бы быть лучшим представлением вашей реальной ситуации.

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

Кроме этого, все, что я могу предложить, - это мои поздравления. Похоже, ты очень внимателен ко мне.

Answer 5

~ 200 мс на запрос - довольно распространенное число, при котором страница кажется «быстрой» для большинства пользователей.