Сайт медленно после очистки кэша

[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]

Фокус в том, - если вы действительно не нужно, то не используйте последней стратегии очистки. Я знаю, что есть если - Вы проверили другие стратегии очистки? Другие не ясно весь кэш и потребует больше ресурсов, чтобы очистить от другой стороны.

Следующая 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 строки кода, с 'OPTIMIZE локальную таблицу». Это позволит сделать действительно быстро удаление без необходимости обновления индексов. Примечание: индексы будут расти, так что вам придется, чтобы выполнить запрос вручную - т.е. проверить его один раз в неделю. Если она будет работать для вас, мы будем осуществлять новую стратегию, где индексы будут реорганизованы не каждый день.

[tavenger5]

Да на vbSEO.

Я использую нормальное удаление в данный момент и она, кажется, не слишком долго, чтобы получить вещи очищаются. С быстрого удаления, местные индексы левой в такт, а нормальные индексы удаления очищаются? Будет ли иметь старые индексы имеют какую-либо выгоду, если они не оптимизированы?

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

Это приятно слышать, что следующая версия будет улучшить скорости снова. Я только убедившись, что не было ничего еще, что я мог сделать с настройки Apache.

[vBET]

Если вы используете нормальной очистки затем забыл о моей подсказки. Я думал, что вы используете последнюю стратегию и удалить весь кэш. Извините - недоразумение Просто оставьте все как есть.

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


То, что вы также можете сделать, это убедиться, что ваш сервер не держит исходящих запросов. Мы обнаружили, что некоторые серверы ведут себя подобным образом, если много исходящих запросов собираетесь же сервере. Из 100 запросов может принять 1000 х больше времени, чем 1 запрос (теоретически должны принимать 100 х больше времени). Это могут быть некоторые брандмауэр, сервер проблема безопасности. Конечно, может быть, что Google ставит какой-нибудь «наказание» в таком случае. Так что если вы можете найти что-то в этой области - это может помочь. Если нет, пожалуйста ждать улучшений