Блог

Сократить время ответа сервера vps

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

Оптимизация скорости сайта: как уменьшить время ответа сервера — Netpeak Blog

Нагрузка на сервер может возникать по трем наиболее частым причинам:. Теперь стоит ещё раз остановиться на ситуации второй — когда вам нужна оптимизация ради оценки Гугла, якобы для продвижения сайта. На самом деле это миф, по большей части. И это практически не влияет на продвижение. Проблемы действительно могут быть, если сайт грузится дольше одной-двух секунд. Тогда это в самом деле может ухудшать поведенческие факторы, и влиять на SEO. Такой загрузки можно добиться обычно только лишь кэшированием, и на этом остановлюсь чуть подробнее далее.

Но без кэширования норма времени генерации страниц сервером для того же wordpress обычно в пределах 0. На очень быстром сервере с дефолтным шаблоном и php 7 пустой вордпресс будет показывать что-то около 0. Если же в вашем случае это ощутимо дольше, то скорей всего можно комплексной оптимизацией настроек софта на сервере добиться более быстрой работы сайтов. Далее будем говорить о том, какие возможности есть для оптимизации настроек и ускорения работы сайтов на сервере. Прежде всего надо говорить об nginx.

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

Апач — прекрасный софт, как раз в силу своей универсальности. Но он не выдерживает конкуренции с режимом php-fpm там, где появляется нагрузка. Он как раз чаще всего и является узким местом в производительности системы.

Но режим имеет значение при ооочень больших нагрузках. Сотни тысяч посещений в сутки. Хотя, иногда и при десятках килоуников могут быть проблемы. Надо понимать, что php-fpm не прибавляет скорости. Он даёт лишь производительность. Что это такое? Это значит, что он позволяет быстрее обрабатывать запросы при больших нагрузках.

Там, где появляется большой трафик — апач начинает захлебываться, потреблять больше ресурсов. Php-fpm же может держать бОльшие нагрузки даже на минимальных аппаратных конфигурациях. Это не значит, что он будет быстрей отдавать страницы. Возьмем типовой сайт на wordpress. Без кэширования, сайт на apache при этих ресурсах будет работать с минимальным временем отклика примерно до посещаемости тысячи посетителей в сутки.

Там конечно еще имеет значение количество хитов, но в среднем из практики цифры примерно. Кейс — как я оптимизировал сайты на недорогом VPS. Особенно в часы пик. Часто эта проблема решается кэширующими плагинами. С ними можно говорить уже о к трафика при такой конфигурации. У меня почти все сайты на wordpress, так я только в таком режиме их и запускаю. Типовая конфигурация для wp имеет примерно такой вид: Это полная конфигурация сайта из наиболее популярной панели управления ISPmanager 5, которую я использую сам, и рекомендую клиентам.

Но это можно настроить на любом сервере. Просто сия панелька позволяет это делать очень легко и удобно. Панель этого не умеет, по крайней мере. Именно она обеспечивает корректную работу ЧПУ, и заменяет привычный файл.

Оптимизация скорости сайта: как уменьшить время ответа сервера

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

Это сохранение некоторых или всех результатов работы от первых обращений к софту в некий кэш в оперативной памяти или на диске. Поэтому при повторных обращениях софт уже может не исполнять код заново, а просто сверить — то что будет получено в виде результата совпадает ли с уже сохранным ранее результатом? И если это так, то просто отдает сохраненый результат, не выполняя работу заново.

Аналогичным образом работает всем известный кэш браузера — он сохраняет на диск ранее полученные файлы сайта —. Итак, теперь можно переходить к подробностям — какая оптимизация делается в том или ином случае, и что за параметры надо крутить. С этим обычно связаны самые большие накладные расходы в работе CMS.

Чтобы это было понятней вам, мне придется объяснить что такое язык PHP. Дело в том, что языки программирования делятся на компилируемые и интерпретируемые. Это значит, что код однажды переводится в машинный язык и в таком виде остаётся, это и есть готовая программа. Поэтому он выполняется очень быстро — сразу в процессор, грубо говоря.

PHP же, и многие другие языки, которые используются ныне для веб-разработки python, js, ruby относятся к языкам интерпретируемым или скриптовым. Это даёт больше гибкости и удобства в разработке, но оказывается сильно медленней и требует гораздо больше ресурсов. Представьте себе, ваш сайт работает на CMS, состоящей из десятков или даже сотен скриптов, которые друг о друга зависят и вызываются один из другого.

Вы запрашиваете всего одну страницу, но к сайту идут десятки запросов для того чтобы эту страницу собрать. Это можно легко увидеть через отладчик браузера. Вот, для загрузки страницы моего блога посылается 66 запросов на сервер. Чаще всего при работе с wordpress запросов около сотни. Обращение к PHP при этом производится к одному скрипту, но тому для получения результата нужно чтобы выполнились десятки или сотни других скриптов.

В случае с wordpress — обычно это index. И каждый из таких скриптов выполняется аналогично — последовательно и на лету. Это уже совсем дебри, но я, пожалуй, покажу вам, как это выглядит изнутри:. У меня не влез в один экран список вызовов скриптов, который я вытащил с помощью ядерного отладчика strace. О нём же и говорит гугл в своей многим непонятной рекомендации о сокращении ответа сервера.

Примерно соответствует, верно? Откуда взялись еще 80 милисекунд? Как видите, на фоне исполнения PHP он молниеносен. Это действительно. В этом легко убедиться, если исключить всю работу php и mysql, оставив отдачу страницы одному только Nginx:. Тут видим всё же не 0,08 сек, а чуть больше — 0, Чем объяснить? Ну да ладно. На последнем скрине — это идеальный вариант отдачи страницы, и о нем будет речь чуть.

А пока вернемся к PHP. Так называемая прекомпиляция. Это не полноценная компиляция, потому что PHP в принципе не может быть скомпилирован.

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

Их есть несколько разных, некоторые из них уже устарели, но все они используют один и тот же принцип кэширования. На тему акселераторов в разных версиях PHP есть на хабре хорошая статьяс наглядными графиками. Впервые я с этим столкнулся когда всюду использовалась версия PHP 5. Я стал использовать это в виде расширения APC, и это стало довольно таки прорывной вещью для меня и проекта, над которым я тогда работал.

Начиная с версии 5. Но на самом деле не. Обычно это дополнительное расширение, которое нужно доустанавливать. Что-то вроде: И чаще бывает так, что акселератор opcache установлен, но работает неэффективно, ибо по-умолчанию ему выделено недостаточно памяти.

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

Исполнить проверку с помощью функции phpinfo. Но и это ещё не всё. Почему — вдаваться в подробности не. Просто потому, что такие особенности у этого режима. Недаром он самый низкопроизводительный. Если вы хотите чтобы opcache работал, то нужно запускать сайт в режиме модуля apache или php-fpm.

Для этого можно добавить в корень сайта файлик opcache. Затем, при обращении по адресу site. Чаще всего вы увидите аналогичную картину. Это значит что акселератору не хватает памяти. Кэшируется лишь часть скриптов. Соответственно, те, что не закэшированы всякий раз исполняются полностью, что снижает производительность веб-сервера. Там же можно посмотреть список закэшированных скриптов и прочие настройки расширения. Эффективность работы можно увидеть на вкладке hits. В данном случае казалось бы эффективность не сильно снижена, что и отражает данная статистика.

Misses — пропуски. Вряд ли у меня там упускается и не попадает в кэш что-то критичное. Вот, а в случае с клиентом, с которого взяты первые три скрина — увеличение памяти повлияло ощутимо. Там нормальные настройки opcache ускорили сайт примерно с 2 сек до 1,3.

Иногда больше, иногда меньше. Нужно искать файлик opcache. В разных системах и разных версиях PHP он может называться по-разному — opcache. Имеет он примерно такой вид:. Итак, для оптимизации требуется подобрать количество памяти в мегабайтах, в очевидном параметре opcache.

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

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

Кэшер всякий раз проверяет изменился ли скрипт, прежде чем использовать кэшированную версию. Это дополнительные ресурсы и время. Отключение этой валидации позволяет добавить еще процентов к производительности выполнения кода. Причем, вам необязательно что-то реально разрабатывать чтобы столкнуться с проблемами. Элементарная настройка шаблона или плагинов через панель управления того же wordpress может глючить. Посему, не используйте эти настройки. Это только opcache. Есть еще apc, который уже устарел, и после версии 5.

Хотя и есть костыли для обратного портирования даже на php 7, но юзать их тот еще гемор. Да и смысла в этом обычно. А вот Xcache в принципе заслуживает внимания. Просто потому что он по эффективности почти не уступает opcache см.

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

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

Поэтому конфиг пула я делаю примерно таким:. Вот это три самые важные параметра, а все остальные можно оставить по-умолчанию. Первое режим. По умолчанию стоит именно dynamic и он самый нестабильный из всех возможных. Static — более стабильный, но ресурсоёмкий. Ибо он сразу запускает все процессы и выделяет на них память, поэтому с количеством процессов в таком режиме нужно быть очень осторожным. Ondemand самый удобный режим. Он работает так же стабильно как статик, но не жрет ресурсы.

Как только ему нужны еще процессы — он их запускает. Не нужны — процессы умирают. Я обычно ставлю в зависимости от мощности сервера. Позволяет избегать зависаний и утечек памяти. Тогда вместо www. Соответственно пулов и конфигов может быть несколько, они могут запускаться параллельно. А во-вторых, у вас может быть использоваться php альтернативной версии, и тогда нужно искать конфигурации пулов в другом месте.

В каком — лучше всего смотреть через phpinfo. Господа, подскажите, пожалуйста, какие настройки необходимо поправить для эффективной работы сайта на Wordpress?

Что можно исправить?

Как уменьшить время ответа сервера?

Sanes Sanes. Сервер настроить. А что это вообще за график? Я так предполагаю, что это время генерации страницы. Буквально сегодня с этими попугаями боролся на ISPmanager 5 Lite.

Как узнать и сократить время ответа сервера

Так вот там например в PHP 7 alt по-умолчанию отключен Zendopcache. После включения разница заметная, примерно в 2 раза. Ответ написан более двух лет.

Нравится 14 комментариев Facebook Вконтакте Twitter Google. Ответ сервера в яндекс метрике за год использования. Написано более двух лет. Мож сервер дрянь? Расширения Joomla Simple Image Gallery. Phoca Gallery — компонент для создания галерей. Balbooa Joomla Forms — продвинутый конструктор форм. Komento — лучший платный компонент комментариев для Joomla. Engage Box: Google Structured Data — компонент для микроразметки в Joomla.

Как добавить материал Joomla в несколько категорий? Slider Revolution: Unite Revolution Slider: Smart Slider 3: JComments — лучший бесплатный компонент комментариев для Joomla 3. Комментарии в Joomla 3: Sourcerer — плагин для размещения кода в контенте сайта на Joomla. ZOO для Joomla 3: Convert Forms — конструктор форм подписки для Joomla.

Оптимизация скорости сайта на #WordPress. Серия #3. Сжатие стилей, скриптов, html

Социальные кнопки для Joomla. Форма обратной связи для Joomla. Дополнительные поля в Joomla 3. Community Builder для Joomla: K2 — конструктор контента для Joomla. AllVideos — плагин Joomla для добавления видео на сайт.

Слайдер для Joomla 3: AcyMailing — компонент email-маркетинга для Joomla 3. Скорость загрузки сайтов на Joomla 8. JCH Optimize — лучшее расширение для ускорения Joomla. Время ответа сервера для сайтов на Joomla. Турбо-страницы Яндекса для Joomla. Мифы о скорости загрузки сайтов на Joomla. Как проверить скорость загрузки сайта на Joomla. Сжатие картинок на сайте Joomla 3 и выше.

Сокращение объема кода в Joomla 3. Кэш в Joomla 3: SEO-оптимизация сайтов Joomla Xmap — устаревший генератор Sitemap для Joomla. Битые ссылки в Joomla. Карта сайта для Joomla 3: Иконка сайта Favicon в Joomla.

ЧПУ в Joomla 3: Как убрать index. Дубли страниц в Joomla 3. Микроразметка сайтов на Joomla 3. Настройка robots. SEO-мифы о Joomla: Тег Title страниц сайта на Joomla 3. Страница ошибки в Joomla 3. Защита и безопасность сайтов на Joomla 7.

RSFirewall для Joomla 3: Как выбрать безопасное расширение для Joomla?

регистрация домена r1