Минимально возможная ожидаемая задержка HTTPS?
На моем сайте средняя задержка (при отсутствии резервного копирования и т. Д.) Составляет ~150 мс для конкретного файла AJAX (суть пользовательского интерфейса). Я сократил это с ~250 мс, выполнив несколько трюков на стороне сервера / базы данных, и я думаю, что есть один последний трюк, который может отбросить его еще на 10 мс или около того от текущего общего ~30 мс для фактической части PHP/MySQL. стр.
Я использую keep-alive, поэтому я думаю, что рукопожатие ssl более или менее полностью завершено (но я надеюсь вскоре перейти к SPDY, так что я не знаю, как это поможет после первоначального рукопожатия).
Когда я пинг, это в среднем ~55 мс.
Я устанавливаю соединение с MySQL в начале файла и закрываю его в конце. Я уверен, что это стоит около 10 мс.
Так откуда берутся оставшиеся ~55мс?
Это может показаться полностью навязчивым, но это для быстрой динамической нумерации страниц, и эффект серьезно ухудшается с каждой задержкой мс.
Спасибо заранее!
2 ответа
Если у вас установлено соединение HTTP, вы сможете выполнить один простой короткий HTTP-запрос примерно в то же время, что и ping.
Чтобы проверить это, сколько времени занимает получение статического файла.
Затем попробуйте получить небольшой кусок данных со страницы PHP, которая не использует никаких библиотек.
Затем попробуйте добавить ваши требования и библиотеки без изменения вывода. Это может быть важно, например, использование Zend и нескольких его пакетов легко занимает 40 мс с xcache и в целом быстрой системой. Вы можете изменить способ запуска PHP, например, apache prefork mod_php должен запустить новый процесс, а php должен загружать библиотеки для каждого запроса. Если вы переключитесь на fastcgi, вы можете предварительно загрузить необходимые библиотеки, заранее открыть соединения с базой данных и убрать соответствующие затраты времени из предполагаемой задержки.
Затем добавьте несколько запросов к базе данных.
Следующее обновление до AJAX.
Теперь AJAX обычно делает запрос POST, что в HTTP 1.1 означает Expect: заголовок 100-continue и добавление еще одного обхода. Попробуйте отключить этот заголовок.
Наконец, запишите свой запрос и ответ и попытайтесь удалить все, что вам не нужно. В идеале вы хотите, чтобы каждый запрос и ответ не превышали 1 КБ, хотя, если ваше соединение поддерживается, окно tcp увеличивается, и через некоторое время, возможно, будет нормально отправлять, скажем, 16 КБ сообщений. Запрос относительно прост - обычно он небольшой, удаляет ненужные файлы cookie и т. Д.; Ответ сложнее, так как это ваши данные, попробуйте сжать или отправить только те данные, которые фактически используются, без форматирования, стилей или чего-либо еще, что можно сделать на стороне клиента.
На все вопросы, связанные с производительностью, единственный ответ - использовать профилировщик. В зависимости от ваших предпочтений, функций профилировщика и других причин, которые вы можете выбрать из списка инструментов (список содержит только те, которые я когда-либо использовал или о которых слышал):