Оптимізація WordPress для зниження навантаження на процесор

1. ненажерливість WordPress
2. Основні причини перевантажень
3. Методи боротьби з навантаженням
4. Блокування запитів на нові версії
5. Автоматичне управління версіями (ревізіями)
6. Плагін WP-Optimize
7. Аналіз «кривизни» вашого сайту

Сьогодні я хочу поговорити про те, як знизити навантаження на сервер хостера, створювану вашим блогом на WordPress. Мені недавно хостинг-провайдер надіслав лист з попередженням про те, що мій блог створює навантаження на сервер вище встановленого для мого тарифу межі. Причому, це було вже друге попередження і тому, не чекаючи третього, я взявся за пошук способів знизити навантаження на сервер, яку створює мій сайт.

ненажерливість WordPress

Як з'ясувалося, щоб сайт на WordPress почав створювати неприпустиму навантаження на процесор сервера, багато не треба: достатньо 15-20 разів поспіль (з паузою не більше 0,75 секунди) клікнути по одній і тій же посиланням або просто відкрити з граничною швидкістю 15- 20 сторінок сайту у вкладках або ж натискати F5 в браузері десяток разів.

Якщо неприпустимою навантаженням провайдер називає вже 5%, то таким ось нехитрим клацанням, якщо дуже постаратися, можна викликати навантаження, якщо вірити логам, до 28 відсотків (!!!). А тепер уявімо, що клікати почав не один користувач, а два? Так, проблема актуальна тільки для віртуального хостингу, та й то є думки, як вони могли б це оптимізувати ... Але тим не менше проблема існує.

Також з'ясувалося, що з кожною новою версією WP стає все прожорливее. Скажімо, якщо версія 2.3.3 споживала менше 10 Мбайт пам'яті, то 2.7.1 - не менше 20.

Практика показує, що мій сайт з купою віджетів іноді споживає до 45-55% процесорного часу. Звідки ж беруться такі цифри?

Картинки, стилі і скрипти - це "статичну вміст". Воно не змінюється з плином часу, і на такі звернення потрібно найменше ресурсів (процесорний час практично не використовується, пам'яті потрібно мінімальна кількість). Втім, якщо до Вас на сайт з виключно статичними матеріалами буде заходити 100 тисяч осіб на добу, навантаження він все одно буде створювати пристойну. Але в нашому випадку основна проблема - це "динамічний вміст".

Скажімо, на Одне відображення Сторінки WordPress 2.8 вітрачає около 19 Мб пам'яті и 1 секунду часу. Це означає, что в течение 1 секунди, всім іншім Клієнтам вашого хостингу недоступно примерно 25 мегабайт пам'яті. Пріпустімо, что у Вас - 100 відвідувачів на добу и в Середньому смороду здійснюють 3 просмтра Сторінки. Значить, Ваш сайт витрачає десь 300 * 25 Мбайт пам'яті протягом 300 секунд. У масштабах цілої доби - все нормально.

Але припустимо, що у сайту починає рости відвідуваність (до 150 осіб на добу), або ж Ви встановили який-небудь супер-пупер новий плагін, і споживання пам'яті WordPress зросла до 30 Мбайт. Таким чином, споживання ресурсів хостера зросла приблизно на 50%. Якщо хостер вважатиме, що Ви споживаєте дуже багато пам'яті і процесорного часу за ті гроші, які Ви йому платите - Вам буде відправлено попередження про можливе відключення сайту і пропозиція змінити тарифний план.

Отже, динамічний вміст - це зайві запити до БД і витрати процесорного часу. Причому, чим більше в коді вашого шаблока запитів до БД, тим більше буде навантаження. Фактично, кожен додається плагін і віджет, які для своєї роботи щось вибирають з бази, створюють зайве навантаження.

Іншими причинами великого навантаження на процесор можуть бути DDoS-атаки і робота пошукових роботів. З урахуванням того, що вони можуть відкривати побагато сторінок поспіль або взагалі одночасно, а банити їх не можна, бо куди ж без них, то можуть знову ж виникнути проблеми з хостером.

Основні причини перевантажень

Основні причини, за якими блог дуже сильно навантажує хостинг:

1. Висновок останніх коментарів (зазвичай ставлять на відображення 10 останніх - а це додаткові 10 запитів до БД)
2. Висновок останніх новин в спеціальному блоці (немає сенсу в цьому блоці, якщо на головній сторінці майже у всіх і відображаються 5-10 останніх новин)
3. Висновок самих коментованих новин (знову ж зайві запити ...)
4. Велика кількість зовсім не потрібних встановлених віджетів.
5. Багато знову ж таки не потрібних встановлених плагінів.
6. Множинні зайві запити в самому шаблоні, які можна замінити на статичну вміст.

Методи боротьби з навантаженням

Для початку, потрібно з'ясувати, що сталося недавно. Можливо, у сайту різко зросла популярність. Можливо, сайт був нещодавно оновлений (встановлена ​​найсвіжіша версія WordPress). Можливо, Ви додали нову сторінку або встановили новий плагін? .. Можливо, Ваш прайс-лист збільшився вдвічі?

Часто проблему можна вирішити шляхом включення кешування. Наприклад, для WordPress це може бути плагін WP-SuperCache . У ModX на потрібних сторінках можна поставити прапорець "Кешована документ". В Drupal це робиться в меню "Налаштування сайту -> Продуктивність". Для Joomla можна скачати PageCache .

Модулі кешування для WordPress: Це WP-Cache, WP Super Cache, Hyper Cache, WP File Cache.

WP-Cache

В принципі - WP-Cache версії 2.0 - розроблений в 2005 році і з того часу останні оновлення проводилися в 2007 році, так що використовувати напевно не бажано в силу все ж великих змін в самому двигуні і виходу версії 2.7.

WP Super Cache

Найпоширеніший в даний час плагін. Автор плагіна - Donncha O Caoimh. Сторінка плагіна - http://ocaoimh.ie/wp-super-cache/.

WP Super Кеш є плагіном статичного кешування для WordPress. Він генерує HTML файли, які обслуговуються безпосередньо Apache без обробки порівняно важких PHP скриптів. За допомогою цього плагіна ви істотно можете прискорити ваш блог WordPress.

недоліки:

- вимагає досить великий дисковий простір для зберігання даних кешування;
- є неусунуті програмні помилки (поки), які часто призводять до "падіння" сервера (почитати можна тут - http://blog.sjinks.org.ua/wordpress/521-wp-super-cache-under-high-load/ );
- досить складний в установці (вимагає редагування wp-config.php і .htaccess) і налаштування.

Hyper Cache

Принцип роботи практично однаковий з WP Super Cache. Теж створення статичних сторінок, їх зберігання та видача при зверненні до сайту.

Сайт автора плагіна - http://www.satollo.com/, домашня сторінка плагіна - http://www.satollo.com/english/wordpress/hyper-cache.

недоліки:

- теж багато пам'яті під кеш сторінок;
- незрозуміла обробка сторінки 404 і укладання в кеш;

- вважається, що його продуктивність при множинних потоках і запитах нижче, ніж у Super Cache.

WP File Cache

Це той плагін, який мені сподобався і який можу Вам порекомендувати. Тому щодо його більше про переваги. А вони такі:

- реалізація довготривалого кешування на рівні запитів;
- повна сумісність з інтерфейсом класу WP_Object_Cache WordPress;
- використання пам'яті під сесійну кеш для збільшення продуктивності;
- сесійне кешування часто змінюються об'єктів;
- зберігання налаштувань в коді плагіна;
- спочатку російською та англійською мовами;
- російський автор, відповідно російська підтримка і Іструкції.

Автор плагіна - Володимир Колесников, домашня сторінка плагіна - http://blog.sjinks.org.ua/wordpress/plugins/190-wp-file-cache-replacement-for-wp_object_cache-with-persistent-caching/.

Про тестування продуктивності кешей можна почитати тут http://blog.sjinks.pro/wordpress/683-wp-supercache-vs-hypercache-vs-w3-total-cache-vs-maxsite-cache/ і в продовженні статті http: / /blog.sjinks.pro/wordpress/725-689-wp-super-cache-vs-maxsite-cache-part-2/

Короткі висновки: на грамотно налаштованому сервері лідирує WP Super Cache - і за швидкістю, і за створюваної навантаженні.

Нещодавно виявився і інший плагін, який працює інакше, ніж звичайні кеші.

Плагін DB Cache Reloaded є інструментом, що забезпечують динамічні кешування запитів до бази даних. Робота цього плагіна базується на зовсім інших, відмінних від плагінів статичного кешування, принципах, і дозволяє істотно збільшити швидкість завантаження блогу і знизити навантаження на хостинг.

Кожен раз, коли формується сторінка блогу, йдуть запити до бази даних, що посилаються темою, віджетами, плагінами. DB Cache Reloaded кешируєт ці запити, направляючи їх в подальшому не в базу даних, а в кеш, доступ до якого більш швидкий. В результаті кількість звернень до бази даних знижується в кілька разів (в моєму випадку, з 25 до 5). Це знижує завантаження процесора і використання оперативної пам'яті - знижується загальне навантаження на хостинг, зменшує час генерації сторінок блогу. Налаштування плагіна мінімальні, є код, який можна вставити в footer.php для відображення часу завантаження блогу, кількості звернень до бази даних і обсягу споживаної оперативної пам'яті.

Завантажити DB Cache Reloaded

Якщо простим кешуванням не обійшлося - потрібен погляд професіонала. Необхідно знайти "поганий" плагін або модуль, і оновити, полагодити або замінити його. Навскидку - можу порекомендувати відключити модулі статистики і використовувати замість них лічильник LiveInternet або Google Analytics. Повна оптимізація сайту може зайняти величезну кількість часу (і грошей), так що усувайте проблеми в міру їх виникнення :)

Блокування запитів на нові версії

Движок WordPress влаштований таким чином, що при кожному вході в адміністративну частину він дивиться, чи не оновився чи який-небудь плагін. Як він це робить? У кожному плагін прописана його сторінка, зазвичай це розділ в каталозі плагінів на сайті wordpress.org. Заходячи туди, він порівнює версію, встановлену в у вас з тієї, що знаходиться на сайті плагіна. Якщо там новіша, то він пропонує оновити плагін.

Те ж саме він робить і по відношенню до самого себе - кожен раз перевіряє, чи не зробили розробники WordPress нову версію. Зрозуміло, що така робота від'їдає у вашого сайту і так ті деякі мегабайти пам'яті, які виділяються провайдером на його функціонування.

Я не звик часто оновлювати плагіни, і, один раз підібравши їх і налаштувавши, віддаю перевагу більше з ними не возитися, сповідуючи принцип "працює - не чіпай!". Тому мені досить три-чотири рази на рік перевіряти, чи не вийшла нова версія якого-небудь, плагіна, а на решту часу відключати цю функцію.

Раніше я робив це руками, виправляючи конфігураційний файл. Так тривало доти, доки Калінін Іван не зробив плагін, який на льоту позбавляє WordPress перевірки на оновлення плагінів. Заодно він відключає і сам WordPress від перевірки на оновлення. Називається цей плагін Блокування запитів на нові версії . Працює плагін просто: активували - працює, не активували - не працює.

Автоматичне управління версіями (ревізіями)

Після того, як виотредактіруете який-небудь пост, WordPress збереже попередній варіант, щоб у разі чого можна було зробити відкат. Але ось невдача - це "в разі чого" у мене трапляється вкрай рідко, і по суті всі ці дублі попередніх версій мого поста мені не потрібні. WordPress робить такі бекапи періодично, і вони все накопичуються і накопичуються. Витрачається місце для них, а движок знаходиться в стані постійного контролю і бекапа. Думаю, що мені це не потрібно, тому я відключаю таку можливість (не сперечаюся, для кого-то може і корисну), а заодно економлю місце на сервері і знижую навантаження на двигун за рахунок зменшення бази даних.

Як і у випадку з перевіркою на поновлення, раніше я робив це вручну, виправляючи файли в текстовому редакторі, але цьому прийшов кінець, коли я знайшов плагін, який робить все це автоматично: управління версіями .

Після установки плагін покаже, у яких постів є версії. Думаю, що вони вам давно вже не потрібні, можете видаляти їх. Після цього непогано б вказати, чи варто вам взагалі робити такі ревізії постів, і якщо і варто, то з якою періодичністю, і в якій кількості. Я взагалі прибрав все.

Цей плагін, як я вже і говорив, дозволяє не захаращувати базу даних зайвою інформацією, а чим менше база даних - тим швидше працює WordPress.

Обидва плагіна хороші перш за все тим, що не треба лізти в код і редагувати його вручну. До того ж, деактивація плагінів призводить до відновлення заводських налаштувань. Це не єдині варіанти прискорення роботи WordPress, але вони - найдоступніші.

Плагін WP-Optimize

Ви знаєте, що при видаленні спамерських повідомлень, вони не видаляються з бази даних, а просто ховаються з очей геть? Не знаю, для чого так придумали розробники WordPress, але особисто мені ця колекція невидимих ​​какашек точно не потрібна. Хоча я її і не бачу, але місце вона в базі даних займає. А вам потрібні ревізії постів?

Я думаю, що після того, як пост опублікований, його проміжні версії не потрібні нікому. Розробники WordPress і на цей випадок мають своє, відмінне від інших, думку - все ревізії зберігаються в базі даних. Не знаю, чи потрібні вони іншим, але я за весь свій час знайомства з WordPress, жодного разу не скористався ревізіями. Щоб позбутися від усього цього непотрібного баласту, можна скористатися плагіном WP-Optimize.

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

Завантажити WP-Optimize

Аналіз «кривизни» вашого сайту

Для того, щоб перевірити скільки ж запитів до бази даних відбувається при завантаженні тієї чи іншої сторінки вашого сайту ви можете скористатися відомим плагіном WP Tuner - скачати плагін WP Tuner . Плагін встановлюється стандартним способом, а саме:

• розпакуйте архів wptuner.zip, використовуючи ftp-менеджер підключіться до вашого сайту і завантажте папку wptuner в папку з плагінами wp-content / plugins / на сервері
• увійдіть в адмінку wordpress і виберете вкладку «Модулі» - «Inactive»
• знайдіть рядок з плагіном WP Tuner і увімкніть її
• Після активації, WP Tuner повинен прописати в wp-config.php свої настройки. Для цього треба тимчасово відкрити цей зайл на запис з правами 666 або прописати невеликий шматок коду вручну.
• Якщо код автоматом не прописано, про це скаже сам плагін у вигляді помилки і її опису.

Тепер можна зайти в адмінку вашого блогу і ознайомитися з настройками плагіна WP Tuner. В адмінці вибираємо з лівого меню Налаштування -> WP Tuner.

Власне, налаштувань то не так вже й багато, до того ж для того, щоб цей модуль почне показувати кількість запитів до бази даних при завантаженні сторінки блогу, взагалі нічого міняти не треба. Потрібно просто перейти на сайт з адмінпанелі (це потрібно для того, щоб ви на сайті були під логіном адміністратора) і відкрити будь-яку сторінку вашого сайту. Після закінчення завантаження перейдіть вниз і ви побачите під футером вашого сайту вікно плагіна WP Tuner. На малюнку, наведеному нижче показано, де можна побачити число запитів до бази даних, яке було вироблено при завантаженні цієї сторінки.

Звичайні відвідувачі сайту, природно, цього неподобства бачити не будуть, тільки адміністратор блогу, тобто ви.

Але подивитися число запитів до бази даних можна і не вдаючись до послуг плагінів. Для цього потрібно отримати доступ до файлів вашого сайту по FTP и відкрити на редагування , Наприклад, файл /wp-content/themes/названіе_вашей_теми_оформленія/footer.php і де-небудь в код цього файлу потрібно вставити наступну конструкцію (місце вставки визначатиме місце виведення кількості запитів в футере або по іншому - підвалі вашого блогу):

1 <? Phpif (is_user_logged_in ()) {?&gt; 2 <? Phpecho get_num_queries (); ?&gt; Queries in <? Php timer_stop (1); ?> Seconds.

В результаті, після завантаження сторінки вашого сайту, в самому низу сторінки ви побачите скільки при цьому було зроблено запитів до бази даних.
Ця інформація буде доступна тільки залогіненним користувачам блогу. Тобто якщо у вас на блозі реєстрація відключена, то цей напис будете бачити тільки ви.

Як зменшити навантаження, створювану пошуковими ботами, можна почитати тут http://n-wp.ru/2074.

Про оптимізацію шаблонів для зниження числа запитів до БД ми поговоримо в окремій статті.

(Переходів: 567, з них сьогодні: 1)

Сподобалася публікація? Чому ні? Залиш коммент нижче або підпишись на feed і отримуй список нових статей автоматично через feeder.