Для WordPress, то практически каждый день получаю письма с просьбой умерить аппетиты этого монстра. Как правило блогеры не задумываются об этой проблеме в начале создания сайта, и остро она стоит уже когда хостер присылает уведомления с угрозой отключить сайт.
Как правило, первое, что делает блогер - это устанавливает кэширующие плагины. Нагрузка, если и уменьшается, то незначительно. Далее, начитавшись «якобы гуру», начинают самостоятельно «оптимизировать» шаблон или даже сам WordPress. Тут можно только посочувствовать, особенно умиляют советы о включении например gzip-сжатия в самом шаблоне. Стоит ли говорить, что подобные действия в самом лучшем случае не приводят к результату вовсе, либо, наоборот нагрузка на сервер ещё больше увеличиватся.
Попробуем разобраться, почему так происходит и что делать в подобных ситуациях.
MaxCache и другие кэшиСамый простой и радикальный способ снизить нагрузку WordPress - это установить мой MaxCache. Мой кэш принципиально отличается от любых других кэширующих плагинов, потому что он не плагин и работает вне WordPress. Если другие плагины загружаются в рамках WordPress, то мой - работает вне, тем самым и достигаются столь высокие характеристики.
Поэтому первая причина, по которой существующие плагины-кэши работают неэффективно - это то, что они сами по себе ресурсоёмкие и для своей работы требуют наличия WordPress. То есть вместо снижения нагрузки, получается с точностью наоборот - нагрузка увеличивается.
«Кэширование» в.htaccessНекоторые плагины для «ускорения» WordPress меняют файл .htaccess , прописывая в нем инструкции для принудительного кэширования файлов для браузеров на длительное время. Технически браузер не загружает файл с сервера сразу, а вначале проверяет его наличие в своём кэше (на компьютере). Для этого он посылает короткий запрос серверу и сервер может возвратить ответ «Файл не изменился». То есть браузер уже не тянет его с сервера, а берёт из своего кэша. Понятно, что скорость загрузки страницы в этом случае возрастает многократно.
Указание «принудительного кэширования» в .htaccess практически не имеет смысла поскольку не зависимо от этих инструкций, первоначально все файлы должны быть загружены пользователем. Поскольку повторных посетителей (раз-два в неделю) гораздо меньше новых, то эффективность такого кэширования небольшая. Кроме того, следует учитывать тот факт, что браузеры достаточно умны и самостоятельно определят нужно ли загружать старые файлы.
Таким образом «кеширование» в .htaccess можно использовать, но это только лишь может сказаться на трафике для повторных посетителей.
Сжатие с помощью gzipДругой частой ошибкой является включение gzip-сжатия. Само по себе сжатие позволяет сократить трафик примерно на 30%, но только для текстовых файлов. Как правило файлы изображений плохо сжимаются и выигрыш будет очень маленький.
Проблема здесь в том, что сжатие требует дополнительных ресурсов сервера, что приводит к ещё большей нагрузке. То есть включать сжатие имеет смысл только выборочно и только при наличии свободных ресурсов сервера .
Само сжатие должно быть включено на уровне сервера. Обычно эту инструкци прописывают в .htaccess .
Не путаем трафик и нагрузку на сервер!Неопытные блогеры иногда мне присылают скриншоты разных онлайн-сервисов о том, что мой кэш якобы не уменьшает «нагрузку». Приходится объяснять, что загрузка сайта пользователем и нагрузка на сервере - совершенно разные вещи.
Нагрузка на сервере характеризуется несколькими основными показателями. В первую очередь - это загрузка процессора (CPU). Обычно измеряется от 0 до 100% (или от 0 до 1). 100% - это значит, что процессор полностью загружен в заданный промежуток времени, например за 1 минуту.
Хостеры как правило учитывают этот показатель и закладывают лимиты в тарифные планы. Например для дешёвых тарифов CPU может ограничиваться 2-3%, а дорогих 10%. При этом предполагается учёт пиков: например в течение 30 секунд сайт может потреблять 70% CPU.
Виртуальный хостинг - это одна большая комунальная квартира. Ресурсы у неё ограничены, а жильцов много. Поэтому, когда один жилец (сайт) засел в туалете на полчаса, другие вынуждены его ждать. Вот поэтому хостеры и лимитируют использование туалета ресурсов.
Проверить использование CPU на сервере можно только, если хостер предоставляет такую возможность. На странице кэша в отзывах есть примеры скриншотов. Возможно ваш хостер предлагает похожую статистику.
Нагрузка в виде «процессорного времени»Когда-то давно хостеры использовали только ограничение на трафик. То есть нужно было платить только за объем скачанной информации. После, сделали трафик безлимитным (точнее очень большим), но ввели ограничение на использование CPU. То есть те же самые сайты, которые раньше спокойно работали на сервере, вдруг стали не укладываться в отведенные лимиты CPU.
Сейчас хостеры придумали очередную «забаву» в виде «процессорного времени». Если раньше был лимит на CPU, который просто не стоит превышать, то процессорные минуты «капают» всегда. Например хостер выделил на аккаунт 100 минут в сутки. Не засисимо от того, превысили ли вы лимиты процессора или нет, берется его загрузка и вся суммируется. То есть даже если за вами очереди в туалет нет, хостер учтёт всё время посещения.
Плохая новость для WordPress-блогеров в том, что, как правило выделенных процессорных минут (обычно 100 минут) хватит примерно для 2 тысяч хостов в сутки. Если посещаемость превышает 2000 посетителей, то для сайта на WordPress превышение процессорного времени будет 10-100% (110-200). То есть хостер вышлет уведомление с просьбой уменьшить нагрузку либо перейти на более высокий тариф.
Потребляемая php-память и MySQLДавно известно, что WordPress-разработчики давно «забили» на оптимизацию своего «движка». Вместо этого тупо увеличили минимальные требования к серверу. Именно поэтому WordPress требует для работы как минимум 32Мб памяти, а для админки 256МБ.
На серверах как правило нет большой проблемы с выделением памяти, поэтому сам по себе этот показатель лишь косвенно показывает качество используемого кода.
Если потребление памяти большое, то это говорит о том, что были загружены множество файлов, было получено много данных, и, скорее всего, нет оптимизации алгоритмов выполнения скриптов/функций: там где можно было ограничиться небольшой выборкой, используются большие массивы данных и ресурсоемкие функции.
Что касается MySQL - запросов к базе данных, то тут более сложная ситуация. Запросы бывают разные. Существую короткие, но затратные по ресурсам sql-запросы, а бывают длинные, но быстрые. То есть в целом, если хостер жалуется на превышение лимитов MySQL, следует провести анализ запросов и выявить медленные. Это задачка для опытного вебмастера, а для рядового блогера решается путем отключения плагинов и/или смены шаблона. Но, в любом случае, использование базы данных достаточно затратно для сервера, поэтому всегда следует стремиться к уменьшению количества запросов MySQL.
Чтобы получить статистику своего сайта добавьте в подвал (как правило файл footer.php ) сайта следующий код:
Этот код выводит потребление памяти, количеств запросов к MySQL и общее время, которое потратил сервер на формирование страницы.
Память должна быть где-то до 15-20МБ (мы говоим о WordPress! Для нормальных сайтов - не более 8-10Мб). Запросов - до 30-40, если их более 100, то не откладывайте вопросы оптимизации. Время будет зависеть от мощности сервера, но обычно приемлемо менее 1 секунды. Причем обязательно нужно снять время несколько раз, просто обновляя страницу (F5): на время может влиять объем трафика страницы и используемого кэша. Я бы рискнул назвать «пограничным» значением - 0,5 секунд. Если время больше, значит нужно подумывать об оптимизации, если более 1 секунды - то тут уже без вариантов.
ТрафикТрафик сейчас особо не влияет на нагрузку сервера, поскольку результирующий php-код по объему занимает небольшую часть трафика. Однако, следует учитывать, что большой трафик напрямую влияет на скорость загрузки страниц посетителями.
Самый простой вариант быстро проверить объем трафика - воспользоваться «Информация о странице» в FireFox.
Думаю, что нормальный размер страницы - менее 50Кб. Если размер больше, то стоит подумать об оптимизации.
Также необходимо заглянуть на вкладку «Мультимедиа». Как правило именно здесь скрывается основной источник повышенного трафика. Вообще любой блогер должен сделить за выкладываемыми файлами и выполнять оптимизацию загружаемых изображений в фотошопе или аналогичных программах. Тут рекомендация одна - чем меньше размер файла, тем лучше. Если размер файла более 100-200Кб, то стоит рассмотреть вариант его размещения в виде миниатюры или даже замены.
Следующий источник трафика - js-скрипты и css-файлы. Можно воспользоваться «Веб-консолью», но удобней воспользоваться расширением HttpFox. HttpFox выдаёт http-заголовки, размер, все адреса и прочую информацию, глядя на которую можно оценить затраты на трафик и время загрузки каждого файла.
Обратите внимание на 304-заголовок - это ответ сервера, что файл не изменился и браузер его возьмет из своего кэша.Очень часто в WordPress"е загружают несколько копий jQuery. Каждая из них весит примерно по 100Кб, так что есть смысл проанализировать кто «безобразничает» и наказать «сорванца». :-)
Также обратите внимание на сторонние скрипты, например счетчики. Строго говоря, анализаторы трафика не должны учитывать сторонние загрузки, но сейчас ситуация такая, что учитывается всё. Например Google Analitics может загружаться за 5 секунд (Яндекс-метрика ещё дольше, да еще и картинку и ссылку свою лепит), это время войдет в общую загрузку. То есть к таким анализаторам следует подходить с умом, отделяя мух от котлет.
Понятно, что основная проблема WordPress"а - это сам WordPress. Точнее наплевательское отношение к оптимизации кода начиная от самих разработчиков, до плагино/шаблоно писателей и самих блогеров. Данный факт в WordPress"е доведен до абсурда. В wp-config.php вы можете ради интереса временно включить режим отладки (точнее отображение ошибок):
Define("WP_DEBUG", true);
Впрочем, ситуацию всё равно не изменить, но можно попытаться хоть как-то минимизировать.
На сервере :
- Проверьте логи php-ошибок на сервере. Если есть какие-то ошибки, то их следует исправить. В любом случае ошибки должны исправляться, а не скрываться.
- Если есть возможность, попробуйте на сервере включить eAccelerator и PHP как fastCGI. Это позволит немного оптимизировать работу PHP и уменьшит расход памяти.
- Если позволяют финансы, то лучше перейти на VDS (виртуальный выделенный сервер). Здесь уже все ресурсы будут своими и никто не укажет на превышение нагрузки. Правда следует учитывать, что как правило VDS слабее обычного виртуального хостинга и скорость работы сайта уменьшится. Думаю, что нет смысла брать VDS с CPU менее 2ГГц и памятью менее 1Гб.
- Учитывайте, что нагрузка на сервере считается по всему аккаунту. Если у вас несколько сайтов, то следует оптимизировать каждый из них.
В самом WordPress :
- Отключите все неиспользуемые плагины. Любой активированный плагин, даже если он не используется, всё равно требует каких-то ресурсов. Такие плагины следует включать только перед использованием. Это касается всяких бэкапов, статистики и т.п.
- Отключите «спорные» плагины, вроде запрета копирования. Это глупость, которая обходится любым пятиклассником. Вообще, все плагины, без которых ваш сайт может обойтись, следует отключить.
- Поменьше работайте в админ-панели. Админ-панель очень прожорлива в создает большую нагрузку, особенно на страницах загрузок файлов.
- Используйте приведенный мной код статистики потребления ресурсов. Чтобы статистика не была видна на сайте, её можно расположить в html-комментарии.
- Количество говнокода в плагинах WordPress - просто поражает! Такое впечатление, что у плагинописателей одна цель - нанести как можно больший вред сайту. Поэтому по возможности проверяйте каждый используемый плагин на нагрузку. Возможно есть аналог, написанный не так похабно.
- Если сайт потребляет слишком много ресурсов, возможно дело в шаблоне. WordPress-шаблоны, к сожалению, часто делаются слишком ресурсоемкими, поскольку разработчики WordPress полностью сосредоточены на красотах админ-панели и не предлагают вебмастерам удобных и эффективных решений. Поэтому они вынуждены придумывать код, который часто не всегда хорош.
Радикально :
- Используйте MaxCache . Он тоже является «костылём», но если другие варианты не помогают, то кэш позволит хоть как-то привести WordPress в чувства. При этом очень осторожно используйте другие кэши. Обязательно отслеживайте показатели статистики до и после. Доверяйте не красивым текстам, а реальным цифрам.
- Смена «движка» на что-то более легковесное, например MaxSite CMS .
Если ничего не помогает :
- Перейдите на более старую версию WordPress. Я бы посоветовал WordPress 2.3.3, причем моей сборки, поскольку в ней реализован lite-перевод, а также подобрана неплохая коллекция плагинов. Шаблон, да, скорее всего, придется переделывать, но оно того стоит: технически шаблоны WordPress застряли в каменном веке и делаются одинаково с версии 1.5.
- Отключите русский перевод. Русский перевод сейчас занимает почти 700Кб. И это только сам файл, не считая ресурсов на его загрузку, обработку и вывод. Отключив русский перевод, можно получить довольно существенное ускорение работы сайта.
Ну и на последок. WordPress - очень прожорлив. Поэтому не нужно думать, будто бы эта проблема обойтет вас стороной. При увеличении посещаемости уже до 200 хостов хостер предложит перейти на более высокий тариф. При 2 тысячах - потребуется уже отдельный сервер или переходить на MaxSite CMS . В любом случае всех этих трат можно было бы заранее избежать, если сразу пользоваться нормальными CMS. ;-)
Многие владельцы сайтов на WordPress задаются вопросами: «Почему мой сайт создает большую нагрузку на хостинг? ». И если одна половина из этих вебмастеров виноваты сами (большое количество ненужных плагинов, плохая оптимизация), то остальная половина действительно не может понять, в чем же дело.
Итак, краткая инструкция для второй половины, как уменьшить нагрузку на хостинг и дополнительно защитить свой сайт на WordPress от взлома.
1) Закрываем xmlrpc.php
xmlrpc.php - это пожалуй самый ненужный файл на сайте, но при этом он часто используется для взлома сайта и создании нагрузки на него.
В файл .htaccess на вашем сайте (в корне) добавляем следующее:
deny from all
Кроме этого, можно зайти в файл функции темы functions.php и вставить следующий код:
Add_filter("xmlrpc_enabled", "__return_false");
Теперь не забудьте удалить следы данной функции. Заходим в файл header.php вашей темы и удаляем строчку кода, которая содержит pingback и xmlrpc.php. Как правило эта строчка выглядит так:
2) Закрываем или ограничиваем админку
Второй причиной высокой нагрузки является подбор паролей. Хакеры пытаются взломать вашу админку, создавая тонны запросов. Ставим дополнительную защиту через тот же .htaccess файл.
2.1) Если вы единственный админ сайта с постоянным IP адресом:
Создаем в папке wp-admin .htaccess файл и вставляем в него:
Order deny,allow deny from all allow from xxx.xxx.xxx.xxx
Вместо Х пишем ваш IP адрес. В итоге, в админку сможете зайти только вы и никто больше. Даже попытаться не смогут.
2.2) Если вас не устраивает предыдущий вариант, вы просто можете дополнительно защитить вашу админку (без плагина):
В файл .htaccess в корне сайта вставляем следующее:
AuthType Basic AuthName "Private zone. Only for administrator!" AuthUserFile /home/p259227/www/сайт.ру/.htpasswd require valid-user SecRuleEngine Off
Сайт.ру - меняем на свой.
Создаем в корне сайта (там же где.htaccess) файл .htpasswd
В этом файле будет содержаться дополнительный логин и пароль. Данная защита осуществляется на уровне сервера, поэтому она довольно надежна. Логин и пароль желательно ставить отличный от логина и пароля на сайте.
Открываем файл .htpasswd и вставляем следующую строку:
Login:$apr1$bHEXXPPA$zhrhn9vOOr/sdsdi3
Где Login - это ваш логин, а после ваш пароль в специальном зашифрованном виде.
Чтобы сгенерировать свой пароль в таком виде, можно воспользоваться различными онлайн-сервисами, к примеру таким: htaccesstools.com .
В итоге вы получаете готовую строчку (зашифрованный пароль), которую нужно вставить в .htpasswd
Если вы получили уведомление о превышении лимита на использование CPU, это означает, что потребление ресурсов процессора вашим аккаунтом превысило суточную норму , установленную тарифным планом.
В письме от провайдера, как правило, сообщаются:
- пункт Договора/Правил, который был нарушен;
- суть нарушения;
- текущее состояние аккаунта;
- предлагаемые меры, которые клиенту необходимо выполнить для возобновления предоставления услуги.
Первое, что необходимо сделать, это понять основную причину, по которой возрасла нагрузка на ЦП.
1. Нагрузка на CPU из-за неоптимальной работы скриптов или неоптимизированной базы данныхОптимизация CMS: Отключите неиспользуемые и тяжелые плагины CMS, настройте кэширование посредством CMS (для WordPress например можно использовать WP Super Cache или WP-cache.com).
Оптимизация базы данных: Запросы к MySQL, которые выполняются более 0,5 секунд, часто создают избыточную нагрузку на дисковую систему сервера и на его процессор. Проверьте логи медленных запросов к БД (можно запросить у хостера) и выполните оптимизацию структуры БД, а также почистите её от неактуальной информации.
2. Избыточное число запросов к сайтуПовышение нагрузки на CPU может быть свидетельством большого количества запросов от поисковых и иных роботов, или, особенно при скачкообразном резком росте - свидетельством DDOS-атаки или Brute-Force атаки.
Проверка источников запросов: откройте лог-файл со статистикой запросов по User-Agent - из него вы сможете понять, какие роботы с какой периодичностью обращаются к вашему сайту (например YandexBot, bingbot). В логах со статистикой по IP-адресам проверьте, не идёт ли с каких-либо IP огромный поток обращений (если да, то возможно это атака на сайт). Узнать больше информации про IP (кому он принадлежит) можно при помощи сервисов Whois.
Настройка ограничения для роботов : Настройте файл robots.txt: установите таймаут обращения роботов к вашему сайту при помощи директивы Crawl-delay:
Для отдельного бота:
User-agent: bingbot Crawl-delay: 10 # задает таймаут в 10 секунд только для бота bingbot
Или сразу для всех ботов:
User-agent: * Crawl-delay: 10 # задает таймаут в 10 секунд для всех поисковых роботов
Настройка ограничений по IP-адресам: Для блокировки доступа по IP добавьте в файл.htaccess, находящийся в корневой папке сайта, следующие строки (в примере ниже блокируем доступ к сайту для IP-адресов 121.123.123.123 и 121.122.122.122):
Order Allow,Deny Allow from all Deny from 121.123.123.123 Deny from 121.122.122.122
3. Реальное увеличение посещаемости ресурсаС развитием сайта посещаемость его растёт, и чем выше посещаемость, тем больше нагрузка на CPU. В случае перехода порога посещаемости в 10000 уникальных посетителей в сутки на обычном виртуальном хостинге сайту будет однозначно тесно и необходимо переносить его на выделенный сервер.
4. Слабый хостингДовольно часто уже при количестве посетителей более 1000 у пользователя возникают проблемы с превышением нагрузки на хостинг. При этом оптимизация сайта и ограничения для роботов не дают особого эффекта и с хостинга продолжают приходить уведомления о превышении нагрузки. Скорее всего, ваш сайт превзошёл возможности оборудования провайдера - в этом случае лучше сразу сменить хостинг на более качественный. Мы уже сталкивались с подобной проблемой на хостинге reg.ru и других, и после перехода на новый качественный хостинг , и проблема исчезла.
После проведенного анализа рынка услуг виртуального хостинга был найден наиболее оптимальный вариант по соотношению Цена/Качество. Рекомендуем бесплатно попробовать этот хостинг , и перейти на него (при заказе введите промо-код сайт и получите скидку 10% на услуги хостинга ).
Здравствуйте, уважаемые читатели блога сайт. C Наступившими Вас праздниками!
В этот промежуток времени (где-то около получаса) админка выдает 502 ошибку, а для посетителей сайт хоть и доступен, но страницы открываются довольно медленно (от 5 до 15 секунд). Если бы кеширование на блоге не использовалось, то и они бы выдавали 502 ошибку. Помогает только либо двукратная перезагрузка сервера, либо тупое ожидание пока все само собой рассосется.
Кроме этого, в моменты высокой нагрузки не работает поиск по сайту и не отправляются комментарии, но это мелочи. В целом ситуация, как вы понимаете, неприятная, хотя и не сказать чтобы критичная. Вроде и терпимо, а раздражает — жуть.
В общем, за WordPress нужен глаз да глаз. Да, движок бесплатный, при этом профессиональный и попросту чумовой, но излишества всякие нехорошие нет-нет да и проскакивают. Вот. В этот раз взгляд тоже зацепился за «что-то новенькое». Это были три строчки кода (а точнее три служебных гиперссылки) опять же в шапке страницы формируемой WordPress:
Немного погуглив я понял, что «это» появилось в WordPress 4.4 и нужно для чего-то (пока смутно представляю для чего — если в курсе, то поясните). Т.к. «это» появилось недавно, то особо много рецептов удаления нагуглить не удалось, а то, что нашлось, работало как-то кривенько (первая ссылка удалялась, но две другие нет, и вести они стали на ту же страницу, код которой был открыт).
В общем, сие пока решил отложить до прояснения ситуации и появления рецептов «купирования ненужных отростков». Да, опять же, если в теме, то расскажите, ибо сильно эти ссылки меня раздражают. Хотя бы для чего они нужны и не несут ли какого диструктива в продвижение блога. Но тут я пока отступил.
Помимо этого в исходном коде был еще и сильно бросающийся в глаза блок:
Помню, что он был и раньше. Помню, что я якобы знал раньше, откуда он взялся, но сейчас сколько ни пытался, никак не мог вспомнить или даже зацепиться за то, откуда это «красота» появилась в шапке блога (на других блогах он тоже присутствовал). Немного мысленно побуксовал я уперся взглядом в слово emoji в коде. Недавно писал . Чуток погуглил и убедился, что таки да — этот код помогает отображать на страницах WordPress эти самые эмодзи смайлики .
Так как emoji смайлы у меня выводятся от силы в двух-трех статьях, то решил это безобразие убрать, для чего и был произведен поиск рецепта в сети. Решение, как всегда в таких случаях, состояло в добавлении фильтров из папки с используемой вами темой оформления WordPress. В общем, находим в нем место окончания какой-нибудь функции (точку с запятой) и туда добавляем несколько строк непонятного (мне), но вполне себе работающего кода:
Remove_action("wp_head", "print_emoji_detection_script", 7); remove_action("admin_print_scripts", "print_emoji_detection_script"); remove_action("wp_print_styles", "print_emoji_styles"); remove_action("admin_print_styles", "print_emoji_styles"); remove_filter("the_content_feed", "wp_staticize_emoji"); remove_filter("comment_text_rss", "wp_staticize_emoji"); remove_filter("wp_mail", "wp_staticize_emoji_for_email");
Это вариант самого полного отключения поддержки эмодзи в WordPress . Хотите в админке оставьте . Все, после этого наступило приятное чувство чистоты кода от всяко разного.
На тех страницах, где я эмодзи все же использовал, пришлось чуток подправить текст. Я просто открыл эти статьи на редактирование в админке и прямо в самом начале (в Html редакторе, а не в визуальном) добавил этот самый код, который удалил из шапки всех страниц:
window._wpemojiSettings = {"baseUrl":"http:\/\/s.w.org\/images\/core\/emoji\/72x72\/","ext":"..min.js?ver=4.4"}}; !function(a,b,c){function d(a){var c=b.createElement("canvas"),d=c.getContext&&c.getContext("2d");return d&&d.fillText?(d.textBaseline="top",d.font="600 32px Arial","flag"===a?(d.fillText(String.fromCharCode(55356,56806,55356,56826),0,0),c.toDataURL().length>3e3):("simple"===a?d.fillText(String.fromCharCode(55357,56835),0,0):d.fillText(String.fromCharCode(55356,57135),0,0),0!==d.getImageData(16,16,1,1).data)):!1}function e(a){var c=b.createElement("script");c.src=a,c.type="text/javascript",b.getElementsByTagName("head").appendChild(c)}var f,g;c.supports={simple:d("simple"),flag:d("flag"),unicode8:d("unicode8")},c.DOMReady=!1,c.readyCallback=function(){c.DOMReady=!0},c.supports.simple&&c.supports.flag&&c.supports.unicode8||(g=function(){c.readyCallback()},b.addEventListener?(b.addEventListener("DOMContentLoaded",g,!1),a.addEventListener("load",g,!1)):(a.attachEvent("onload",g),b.attachEvent("onreadystatechange",function(){"complete"===b.readyState&&c.readyCallback()})),f=c.source||{},f.concatemoji?e(f.concatemoji):f.wpemoji&&f.twemoji&&(e(f.twemoji),e(f.wpemoji)))}(window,document,window._wpemojiSettings); img.wp-smiley, img.emoji { display: inline !important; border: none !important; box-shadow: none !important; height: 1em !important; width: 1em !important; margin: 0 .07em !important; vertical-align: -0.1em !important; background: none !important; padding: 0 !important; }
Все, получил удовлетворение хотя бы от частичного решения проблемы с чистотой исходного кода и продолжил заниматься рутиной (написанием статей и прочей ерундой).
Как пришло осознаниеОднако, на следующий день закралось сомнение — что-то давно багов не было. Вроде уже долго с сайтом работаю, а 502 в админке не возникает. Верить в чудо было не с руки, ибо уже раз десять начинал праздновать победу, а очередной зависон возвращал меня на землю.
Однако, подождав еще немного по ходу вспомнил, что при поиске решения по удалению поддержки эмодзи запомнилось, что этот код появился в WordPress начиная с версии 4.2, а ведь она вышла как раз весной, когда у меня и начались траблы. Вполне вероятно, что именно это обновление WordPress до очередной версии и стало причиной появления бага с эпизодически высокой нагрузкой.
Во всяком случае по срокам и по тому, что проблема не проявляется после удаления кода поддержки эмодзи, можно было сделать определенные выводы. Я их сделал и написал этот пост. Если проблема вылезет опять, то чуть ниже появится P.S. с сожалениями по поводу напрасно потраченного времени (вами на чтение, а мною на написание).
Решение получилось действительно несуразным, по крайней мере глядя с моей, крайне невысокой в умственном плане, колокольни. Где логика? Не знаю, но все равно приятно, что пусть и случайно, но мучивший меня довольно долго технический казус более-менее удачно разрешился. За сим разрешите откланяться. Спасибо за внимание и еще раз с Наступившими праздниками.
Удачи вам! До скорых встреч на страницах блога сайт
посмотреть еще ролики можно перейдя на ");">
Вам может быть интересно
Пропало левое меню в админке WordPress после обновления
Где скачать WordPress - только с официального сайта wordpress.org
Установка WordPress в деталях и картинках, вход в админку WP и смена пароля
Пустая страница при просмотре больших постов (статей) в WordPress
Снижение потребляемой в WordPress памяти при создании страниц - плагин WPLANG Lite для подмены файла локализации
Как войти в админку WordPress, а так же поменять логин и пароль администратора выданные вам при установке движка
Приветствую всех читателей блога сайт. Рано или поздно перед каждым автором блога на WordPress возникает вопрос - Как снизить нагрузку на сервер? Кто-то задумывается об этом заблаговременно (обладая знаниями), а другие (новички) когда начинают приходить письма «счастья» от хостера. Становится ещё печальнее когда периодически начинает происходить отключение блога за превышение лимитов.
Со мной подобная история произошла в 2010 году. Посещаемость на моём первом блоге наконец-то появилась, медленно и уверенно подрастая. Радоваться долго не пришлось. Вскоре со мной произошло именно то, о чём я описал выше.
Все замечательно, все понравилось, кроме цены - 30 $. Тогда он стоил именно столько.
Миллионы с моего блога не капали, и я прошёл мимо, оставив использование варианта кеширования с MaxCache на потом. Решил же я свою проблему с повышенной нагрузкой на сервер по-другому. После очередного предложения поменять тарифный план, я поменял хостинг.
И вот настал день когда я впервые, вместо одного из вордпрессовских плагинов для кеширования, установил MaxCache. В 2013 году делая блог о спутниковом телевидении, я решил использовать для кеширования блога именно его.
Поюзал два дня бесплатную лайт-версию, укрепился во мнении, что иду правильным путём, и приобрёл платную Full-версию.
Теперь, когда я делаю кому-либо блог, или запуская что-то своё, не задумываясь, устанавливаю для кеширования блога MaxCache.
Как видите, и на этом блоге для снижения нагрузки на сервер стоит именно он. На сегодняшний день цена MaxCache составляет 10 $.
Алгоритм работы - как MaxCache снижает нагрузку на серверДля наглядности сделал скриншоты с футера главной страницы сайт создаваемой нагрузки на сервер до использования скрипта кеширования, и после подключения MaxCache.
Для тех, кто не знает как вывести информацию о нагрузке на сервер, количестве запросов, и время генерации страницы, подскажу. Делается все очень просто.
Открываете файл footer.php вашей темы, и вставляете следующий код перед закрывающимся тегом .
|
Нагрузка на сервер снизилась более чем в 14 раз!
Количество обращений к базе данных при использовании скрипта нулевое!
Скорость генерации страницы увеличилась в 2720 раз!
Цифры это хорошо, но даже и без них чисто визуально становится заметной более шустрая работа блога. Страницы открываются намного веселее.
По какому принципу работает скрипт кеширования? Пользователь, зашедший на ваш сайт, открыл интересующую его страницу, MaxCache тут же поместил её как статическую в папку Cache. Теперь она отдаётся пользователям именно из этой папки без запросов в базу данных, и без дополнительной нагрузки на сервер.
Кеш страниц сбрасывается каждые 4-е часа. При желании можно указать собственные настройки.
В комплекте со скриптом идёт плагин, который при активации позволяет нам когда мы залогинены, и работаем в админ панели блога просматривать не кешированные актуальные версии страниц. Для посетителей в это время, как и положено скрипт выдаёт их из кеша.
Имеется возможность включения gzip-сжатие трафика. Увеличивает скорость загрузки «тяжёлых» страниц. Включение gzip-сжатия даёт дополнительную нагрузку на сервер. Включать или нет эту функцию нужно принимать решение исходя из наличия лимитов по нагрузке CPU. Перед включением gzip-сжатия нужно уточнить у хостера поддерживается ли эта функция сервером.
Я на страницах при написании статей часто использую картинки и скриншоты. Хотя и сжимаю их по максимуму, вес выходит не всегда такой какой бы хотелось. У меня gzip-сжатие включено.
Результаты для главной страницы получились следующие.
До сжатия вес моей страницы был 23,7 KB, после компрессии 6,5 KB. Экономия составила 72,4%. Как говорится - Без комментариев. Сервис проверки работы gzip-сжатия находится по этому адресу - http://www.whatsmyip.org/http_compression/ .
Также в отдельном файле в настройках скрипта можно задать список страниц с запретом на кеширование. При выходе новой версии скрипта, обновление для всех клиентов бесплатное.
В завершение статьи, хотелось бы подчеркнуть, что мне нравится подход автора скрипта к его продажам. После оплаты MaxCache покупатель получает Lite -версию скрипта. Эта версия с ограниченным функционалом. Отличается она от Full-версии, тем, что кеш не сбрасывается на автомате. То есть урезанная версия работает, практически так же, как и полная. На тестирование автор выделяет две недели времени. Далее, вы или отказываетесь от приобретения, и автор возвращает вам деньги либо отправляете заявку на получение full-версии MaxCache.
Я при покупке этого девайса для снижения нагрузки на сервер попросил выслать мне сразу полную версию, так как давно уже знаком с работой скрипта и доволен его работой. Для блога на WordPress MaxCache идеальное решение.
Вконтакте
