Я пытаюсь выяснить эффективность моего кода на стороне сервера.
Используя microtime(true) для измерения скорости, я могу рассчитать время, microtime(true) на выполнение моего сценария.
Я получаю средние скорости от .3 до .5 секунды. Эти сценарии выполняют ряд запросов к базе данных, чтобы вернуть пользователю разные значения.
Что считается эффективным временем выполнения PHP-скриптов, которые будут запущены в Интернете для веб-сайта?
Я знаю, что это зависит только от того, что делается, но просто подумайте об этом стандартном скрипте, который читает из базы данных и возвращает значения пользователю. Я смотрю на Google и вижу, как они ищут в Интернете через .15 секунды, и я чувствую, что мой скрипт – дерьмо.
Время рендеринга целевой страницы YouTube составляет <100 мс ( видео здесь @ 7: 00).
Ваше узкое место, вероятно, является запросом DB – попробуйте использовать
EXPLAIN select * from x...
чтобы увидеть, можете ли вы добавить индексы, которые ускорят ваши запросы.
править ссылка выше умерла. Высокая масштабируемость сделала функцию на YouTube, которая использовала это видео в качестве основного источника, поэтому он может представлять определенный интерес: http://highscalability.com/youtube-architecture
Хм … Я не уверен, что абсолютная ценность здесь довольно справедлива. Это действительно зависит от аппаратного обеспечения … Когда я разрабатываю локально, моя машина разработки работает примерно в 5-10 раз медленнее, чем сервер actuel. Поэтому, если взять абсолютное значение, «приемлемый» диапазон будет варьироваться в зависимости от аппаратного обеспечения.
Ну, обычно я стараюсь держать вещи ниже 100 мс. Если время загрузки сервера выше, я прослежу выполнение и попытаюсь выяснить, что не так. Я должен сказать большую часть времени, база данных (следовательно, запросы) является узким местом. Настоящая работа над этим действительно важна.
Кажется немного выше для меня.
Для справки, моя инфраструктура, которую я создал, получает время выполнения всего 0,0028 и достигает 0,340 секунд. В среднем каждая страница обычно имеет между 11 – 18 SQL-запросами.
Однако имейте в виду, что это высоко оптимизированная структура, использующая кеширование, очень тщательное кодирование запросов и автозагрузку. Попробуйте реализовать эту тактику, и вы должны увидеть значительное улучшение.
Нужно ли быть быстрее и почему?
Если ответ «Да, потому что он находится в списке требований» или «Потому что он берет ценные ресурсы сервера» , попробуйте оптимизировать ваши SQL-запросы. Возможно, вам нужно добавить индекс (ы) …
В противном случае, я думаю, вы должны перейти к следующей задаче. Во-первых, он работает, а во-вторых, вы говорите о 0,3 до 0,5 сек. который должен быть достаточно быстрым для людей и машин.
Это, конечно, очень субъективно, зависит от сайта и т. Д. И т. Д.
Тем не менее, я бы сказал, что, когда страница начинает занимать больше, чем около 100 миллисекунд, это заметная задержка для пользователя, и это может быть «слишком долго». Вот если бы это была страница, которую можно разумно ожидать мгновенно загрузить. Если страница является поисковой страницей, делая полнотекстовый поиск в большой базе данных, ситуация, конечно, отличается.
С PHP большинство веб-сайтов генерируются так быстро, что самая большая задержка – это рендеринг страниц, включая все вспомогательные запросы, такие как изображения для отображения.
Но также скорость и качество интернет-соединения посетителя, его компьютер и его программное обеспечение являются важными факторами.
Чтобы быть щедрым, скажем, PHP занимает 20% от общей загрузки и времени рендеринга веб-страницы.
И снова, я знаю, что этот процент очень приближен, но это больше для иллюстративного примера.
Среднее время загрузки страницы составляет около 3 секунд. (что слишком много). Хорошие качественные веб-сайты должны занимать около 1 секунды для полной загрузки, поэтому для генерации вывода PHP будет разрешено 200 мс (20% от 1 секунды). Таким образом, php может занять до 600 мс для «среднего» веб-сайта.
Примечание. Время выполнения PHP можно улучшить, изменив хостера или улучшив исходный код.
Я бы сказал, что в 10 раз меньше будет нормально. Однако количество запросов не имеет значения. Их может быть 20, все работают на 0,005 сек. Качество имеет значение, а не количество. Профилируйте свой код, чтобы определить наиболее медленные части, добавив еще несколько заявлений о microtime, найдите самую медленную часть и затем оптимизируйте ее.
Если у вас есть собственная функция для запроса mysql, чтобы разместить материал microtime, было бы очень удобно
Зависит, как указано, но, кроме того, учтите следующее: с одним секундой исполнения вы сможете обслуживать (в идеальных условиях) только один запрос в секунду на серверной машине с одним ЦП и где на этом нет ничего другого машина. Если у вас больше запросов, чем в секунду, вы получите длинную очередь, и ваш сервер будет работать ровно, заставляя входящие запросы занимать еще больше времени для обработки. Если вы получаете меньше запросов, вам все равно нужно обратить внимание на использование вашего ЦП. Если сервер загружен уже ранее, у вас может возникнуть проблема, с которой нужно следить.
Существуют математические методы (теория массового обслуживания), которые можно использовать для анализа требований к емкости, см., Например, PDQ ( http://www.perfdynamics.com/Tools/PDQ.html ).
Сравнение с Google, возможно, не может быть справедливым, поскольку у них должно быть огромное количество входящих запросов, и в 3 раза более длительное время выполнения им потребуется в несколько раз больше серверов, чем у них уже есть …
Цель <200 мс.
Люди все чаще начинают терять терпение за tings, которые занимают> 200 мс.
На самом деле все относительно. Не ожидайте, чтобы получить время наравне с другими сайтами с помощью PHP. Помните, PHP должен загружать все с нуля при каждой загрузке страницы.
Действительно, вы хотите посмотреть, насколько хорошо ваш сайт работает под нагрузкой, например, используя Apache ab для его проверки. Если ваш сайт может обрабатывать самый высокий уровень трафика, который вы можете ожидать, вам больше не нужно его оптимизировать. Пользователь не сможет определить, загружена ли ваша страница на 0,75 секунды или 0,25 секунды.
Помните, что вызов microtime само по себе добавит времени на загрузку вашей страницы, поскольку он должен сделать вызов операционной системе (контекстный переключатель). Возможно, более важно оптимизировать страницу, уменьшив ее, чтобы она быстрее переходила по сети и выполнялась быстрее на клиенте.
Я замечаю, что в качестве редактора в Википедии мы не видим жалоб, пока инициация загрузки страницы не превысит где-то около 5-10 секунд. Конечно, механизм сообщения о такой медлительности неясен большинству пользователей.
Для себя – как пользователя веб-сайтов для путешествий – я достаточно умиротворен промежуточным экраном, в котором говорится: «Получил ваш запрос, теперь он обрабатывается, а может потребоваться до X секунд».
Я бы не сравнил ваш скрипт с Google, если вы не поддерживаете аналогичный рейтинг страниц и т. Д.
Если поиск просто извлекает значения из базы данных, скорость может быть улучшена с помощью профилирования приложения и устранения флаконов (например, несколько сценариев на странице, большие изображения, большие таблицы, индексы базы данных)