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

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

  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-скрипта. Что случилось? Как уменьшить эту частоту отказов?

Спасибо, Алек


php performance profiling benchmarking
person Alec Smart    schedule 28.01.2009    source источник

Ответы (5)


arrow_upward
7
arrow_downward

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

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

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

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

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

person Gary Richardson    schedule 28.01.2009

arrow_upward
1
arrow_downward

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

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

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

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

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

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

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

person duffymo    schedule 28.01.2009

arrow_upward
1
arrow_downward

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

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

person Greg    schedule 28.01.2009

arrow_upward
1
arrow_downward

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

Затем используйте webgrind, чтобы просмотреть профиль в удобном формате.

person lo_fye    schedule 28.01.2009

arrow_upward
0
arrow_downward

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

person Karsten    schedule 28.01.2009