Что считается длительным временем выполнения?

Ответ 1

Время рендеринга целевой страницы YouTube равно < 100 мс (Видео здесь @7: 00).

Ваше узкое место, вероятно, является запросом DB - попробуйте использовать

EXPLAIN select * from x...

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

изменить, ссылка выше умерла. Высокая масштабируемость сделала функцию на YouTube, которая использовала это видео в качестве основного источника, поэтому он может представлять определенный интерес: http://highscalability.com/youtube-architecture

Ответ 2

Мне кажется немного дороже.

Для справки, моя структура, которую я создал, получает время выполнения всего 0,0028 и достигает 0,340 секунды. В среднем каждая страница обычно имеет от 11 до 18 SQL-запросов.

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

Ответ 3

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

Чтобы быть щедрым, скажем, PHP занимает 20% от общей нагрузки и времени рендеринга веб-страницы.
И снова, я знаю, что этот процент очень приближен, но это больше для иллюстративного примера.

Среднее время загрузки страницы составляет около 3 секунд. (что слишком много) Веб-сайты хорошего качества должны занимать около 1 секунды для полной загрузки, поэтому для генерации вывода PHP будет разрешено 200 мс (20% от 1 секунды). Таким образом, php может занять до 600 мс для "среднего" веб-сайта.

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

Ответ 4

Хм... Я не уверен, что абсолютная ценность здесь довольно справедлива. Это действительно зависит от аппаратного обеспечения... Когда я разрабатываю локально, моя машина разработки работает примерно в 5-10 раз медленнее, чем сервер actuel. Поэтому, если взять абсолютное значение, "приемлемый" диапазон будет варьироваться в зависимости от аппаратного обеспечения.

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

Ответ 5

Нужно ли быть быстрее и почему?

Если ответ "Да, потому что он в списке требований" или "Потому что он берет ценные ресурсы сервера", попробуйте оптимизировать ваши SQL-запросы. Возможно вам нужно добавить index (es)...

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

Ответ 6

Это, конечно, очень субъективно, зависит от сайта и т.д. и т.д.

Однако, я бы сказал, что, когда страница начинает занимать больше, чем около 100 миллисекунд, это заметная задержка для пользователя, и это может быть "слишком длинным". Это, если это страница, которую можно разумно ожидать мгновенно загрузить. Если страница является поисковой страницей, выполняющей полнотекстовый поиск в большой базе данных, ситуация, конечно, отличается.

Ответ 7

Я бы сказал, что в 10 раз меньше было бы в порядке. Однако количество запросов не имеет значения. Их может быть 20, все работают на 0,005 сек. Качество имеет значение, а не количество. Профилируйте свой код, чтобы определить наиболее медленные части, добавив еще несколько заявлений microtime, найдите самую медленную часть и затем оптимизируйте ее.

Если у вас есть собственная функция для запроса mysql, для размещения материала microtime было бы очень удобно

Ответ 8

Зависит, как указано, но, кроме того, учтите следующее: с одним секундой исполнения вы сможете обслуживать (в идеальных условиях) только один запрос в секунду на серверной машине с одним ЦП и где нет ничего другого происходит на этой машине. Если у вас больше запросов, чем в секунду, вы получите длинную очередь, и ваш сервер будет работать ровно, заставляя входящие запросы занимать еще больше времени для обработки. Если вы получаете меньше запросов, вам все равно нужно обратить внимание на использование вашего ЦП. Если сервер загружен уже ранее, у вас может возникнуть проблема, с которой нужно следить.

Существуют математические методы (теория очередей), которые можно использовать для анализа требований к емкости, см., например, PDQ (http://www.perfdynamics.com/Tools/PDQ.html) для больше.

Сравнение с Google, возможно, не справедливо, поскольку у них должно быть огромное количество входящих запросов, и в 3 раза больше времени выполнения им потребуется в несколько раз больше серверов, чем у них уже есть...

Ответ 9

Цель для < 200мс.

Люди все чаще начинают терять терпение за tings, которые занимают > 200 мс.

Ответ 10

Все это относительное, действительно. Не ожидайте, чтобы получить время наравне с другими сайтами с помощью PHP. Помните, PHP должен загружать все с нуля при каждой загрузке страницы.

Действительно, вы хотите посмотреть, насколько хорошо ваш сайт работает под нагрузкой, например, используя Apache ab для тестирования. Если ваш сайт может обрабатывать самый высокий уровень трафика, который вы можете ожидать, вам больше не нужно его оптимизировать. Пользователь не сможет определить, загружена ли ваша страница за 0,75 секунды или 0,25 секунды.

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

Ответ 11

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

Для себя - как пользователя веб-сайтов путешествий - я достаточно умиротворен промежуточным экраном, в котором говорится: "Получил ваш запрос, теперь он обрабатывается. Это может занять до X секунд".

Ответ 12

• Я бы не сравнивал ваш script с Google, если вы не поддерживаете аналогичный рейтинг страницы и т.д.

• Если поиск просто извлекает значения из базы данных, скорость может быть улучшена на профилирование приложения и устранение шеек бутылок (например, несколько - script на странице, большие изображения, большие таблицы, индексы базы данных)

Ответ 13

Я создал WP-сайт, на котором на одной из его страниц выполняется довольно сложная процедура поиска и сбора сводной статистики.

Соответствующий модуль PHP получает примерно 500 записей из БД и затем декодирует каждую из них, запрашивая БД для получения более подробной информации, скажем, о 10 различных настраиваемых полях, чтобы объединить все необходимые дополнительные данные для внешнего интерфейса.

Затем он возвращает только страницу данных (скажем, 20 элементов) и статистическую информацию (еще 10 элементов).

Глядя на мой Chrome Dev инструменты времени

• моей локальной машине разработки требуется ~ 0,9 - 1,1 с для TTFB для каждого запроса XHR, который инициирует процедуру, описанную выше.
• Реальный веб-сервер на довольно хорошем виртуальном хостинге для той же страницы требует 0,3-0,6 с для TTFB.

Очевидно, что это не чистый показатель производительности БД, Apache и PHP <-> MySQL мешают синхронизации, но в качестве приблизительного показателя он вполне может быть использован. Никакие рукопожатия SSL и т.д. Издержки соединения представлены здесь. Просто сервер потратил время на подготовку данных и ответ, никакой перезагрузки страницы, так как это запрос XHR.

Если рассматриваемый сайт в пиковый час имеет 100 посетителей/час, посещающих ту же самую загруженную БД страницу в пиковый час, то это всего лишь ~ 2 пользователя/минуту, поэтому с вашим запросом на 0,5 секунды/посетителя вы можете обслужить 60 посетителей/минуту и назовите это узким местом. Очевидно, что в этом воображаемом случае запасная производительность огромна.