Сайт повільно після очищення кешу

[tavenger5]

Я пройшов через і реалізуються всі можливі прийоми оптимізації я можу знайти. Це включає в себе Nginx в якості проксі для Apache, vbOptimize з Memcached, і всі звичайні процедури оптимізації форуму.

Я працюю з двома двопроцесорних серверів чотириядерних процесорів з 12-и *** оперативної пам'яті, і 15k SAS дисків в рейд. Тобто, іншими словами, сервери мають достатню потужність для обробки все.

Основний сайт починає сповільнюватися відразу після кеш vBET очищається кожні 15 днів. (База даних отримує трохи більше *** після цього 15 днів)> 500k сторінок на день, сканується пошукачами.

Є все, що я можу зробити для налаштування Apache для обробляє ці запити краще? Це мої поточні налаштування Apache:
від HTTPD-mpm.conf
# Prefork MPM

StartServers 20
MinSpareServers 20
MaxSpareServers 25
MaxClients 180
MaxRequestsPerChild 1000
З HTTPD-default.conf:

Вийшло 150
KeepAlive On
MaxKeepAliveRequests 80
KeepAliveTimeout 3
UseCanonicalName Off

[vBET]

Дозвольте мені вгадати - у вас є vBSEO і безліч посилань на головній сторінці - я правий? ;)

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

Наступна vBET 3.x реліз може допомогти вам - ми будемо додавати нові додаткові параметри продуктивності для дійсно великих сторінок. Ми також виявили, вузьке місце з перекладом посилання. На даний момент ми впровадили рішення для VB Дружні URL в vBET4.x (ще не випущений), і ми спробуємо прийняти його і для vBSEO. Якщо нам вдасться ми будемо рухатися вона також vBET 3.x питання в тому, що vBSEO просить посилання одну за одною, і це справляє десятки запитів Google. Як я вже писав, ми вже впровадили рішення для URL, В. Б. Frinedly - ми зробили затримки перекладу. Проблема з vBSEO тому, що вона працює поза В.Б., після переведення відбувається, і також не говорять чи потреби URL, щоб перевірити правильність фактичної
або покласти його у вихідний.
Лот деталей - найближчим часом ми знаємо одне вузьке місце, що відбувається тільки тоді, коли кеш не заповнений, і ми вже працюємо над цим питанням.

Так що в цей момент я можу просто раджу вам грати з розчищенням стратегії та інші параметри оформлення. Для інших стратегій:
- Якщо очищення кеша одній таблиці не вбивство вашого сервера, а потім встановити більше "Кеш очищення timelap '- ваш сервер буде перевести дух між полянами
- Analise вашого форуму трафіку і перевірити, коли він менше - зміна очищення виконання до цього часу
- Встановити нижній кеш TTL - маленькі таблиці будуть видалені так очищення сама займе менше ресурсів. Інша сторона - сервер доведеться просити Google частіше для переказів.
- Експериментальні: "Швидкий місцевих видалення з оптимізації таблиць набір відкритих / входить / vbenterprisetranslator_functions.php і коментувати там 3 рядки коду, з" Оптимізувати локальну таблицю. Це дозволить зробити дійсно швидко видалення без необхідності оновлення індексів. Примітка: індекси будуть рости, тому що вам доведеться, щоб виконати запит вручну - тобто перевірити його один раз на тиждень. Якщо вона буде працювати для вас, ми будемо здійснювати нову стратегію, де індекси будуть реорганізовані не кожен день.

[tavenger5]

Та на vbSEO.

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

Речі тільки, здається, сповільнюється, коли є велика кількість трафіку на сайті і Кеш відновлюється. Я впевнений, що це тому, що Apache процеси не закриваються так само швидко, як звичайно (так як дані будуть запитані у Google).

Це приємно чути, що наступна версія буде поліпшити швидкості знову. Я тільки переконавшись, що не було нічого ще, що я міг зробити з налаштування Apache.

[vBET]

Якщо ви використовуєте нормальної очистки потім забув про мою підказки. Я думав, що ви використовуєте останню стратегію і видалити весь кеш. Вибачте - непорозуміння:) Просто залиште все як є.

У таких, як я можу порадити встановити більший кеш TTL. Менш дані будуть видалені кожен раз, так що менше даних буде відновлюватися.
Як я вже писав, ми вже знайшли одне вузьке місце з vBSEO + порожній кеш, і ми працюємо над цим:)

Те, що ви також можете зробити, це переконатися, що ваш сервер не тримає вихідних запитів. Ми виявили, що деякі сервери ведуть себе подібним чином, якщо багато вихідних запитів збираєтеся ж сервері. З 100 запитів може прийняти 1000 х більше часу, ніж 1 запит (теоретично повинні приймати 100 х більше часу). Це можуть бути деякі брандмауер, сервер проблема безпеки. Звичайно, може бути, що Google ставить який-небудь «покарання» у такому випадку. Так що якщо ви можете знайти щось в цій галузі - це може допомогти. Якщо ні, чекати покращення:)