Помощь Нагрузка на DLE

[kodges]

А теперь товарищи самое интересное и вкусное )))
Новый вариант кеширования с использованием memcached.
Про то как устанавливать memcached на сервере и библиотеку для его работы с php я писать не буду. Вам достаточно обратиться к вашему хостинг провайдеру и вам его установят. А тот кто сам администрирует свои сервера тот и сам знает как его ставить Там все делается за пару секунд...
Я расскажу непосредственно о том как этот самый memcached использовать с пользой для вашего сервера, приминительно непосредственно к движку DLE (любой версии).

Единственное скажу что необходимо выделить оперативки для memcached примерно 3 четверти от того сколько занимало у вас файловое кеширование. То есть если файловый кеш скажем со сроком жизни 3 часа занимал у вас 200 мегабайт, то для memcached выделите 150 мегабайт памяти.

Итак начнем...

1. Открываем index.php, находим:

define ( 'DATALIFEENGINE', true );

Вставляем выше:

////////////////////////////////Кеширование в Memcached ///////////////////////////////////////////
if( $_SESSION['dle_user_id'] == false && $_SERVER['REQUEST_METHOD'] == "GET" )
{
	$memcache = memcache_connect( 'localhost', 11211 );
	$memkey = md5( $_SERVER['SERVER_NAME'] . $_SERVER['REQUEST_URI'] );
	$mempage = memcache_get( $memcache, $memkey );
	if( $mempage ) exit( $mempage );
}
///////////////////////////////////////////////////////////////////////////////////////////////////

Находим:

GzipOut ();

Вставляем выше:

////////////////////////////////Кеширование в Memcached ///////////////////////////////////////////
if( $_SESSION['dle_user_id'] == false && $_SERVER['REQUEST_METHOD'] == "GET" )
{
	memcache_set( $memcache, $memkey, ob_get_contents(), MEMCACHE_COMPRESSED, 3600*2 );
	memcache_close( $memcache );
}
///////////////////////////////////////////////////////////////////////////////////////////////////

3600*2 это время жизни кеша, 3600 секунды это 1 час, умножаем 3600 на 2 получается время жизни 2 часа.

2. Всё! Наслаждаемся процессом.

Немного о плюсах и минусах данного способа кеширования. Ну во первых, кеширование похоже на файловое, показанное мною несколькими постами выше.
Плюсы.
1. Еще более быстрый ответ сервера, так как все данные кеша хранятся в оперативной памяти.
2. Никакой нагрузки на HDD. (Меньше износ, больше проживет)
3. Кеш занимает меньше места, так как он сжимается средствами memcached.
4. Как вы могли заметить, я не привел ничего для удаления устаревшего кеша. А все потому что как только время его жизни устаревает в памяти, память занимаемая старым кешем высвобождается сама.

Минусы.
1. Необходимо чтобы у вас было нужное количество оперативки.
2. Если на сервере несколько сайтов, и все они используют данный вид кеширования, то при очистке кеша, удаляется кеш для всех сайтов. То есть невозможно удалить весь кеш только для одного конкретного сайта. С оперативкой такие фокусы не проходят. Либо все либо ничего... Но меня этот факт не сильно напрягает.
3. Больше минусов не вижу

Да кстати, для того чтобы очистить весь кеш в памяти, необходимо запустить такой вот скрипт:

<?php
$memcache = memcache_connect( 'localhost', 11211 );
memcache_flush( $memcache );
memcache_close( $memcache );
?>

После выполнения этого скрипта, ОЗУ не очищается моментально, но весь кеш в памяти помечается как устаревший, а система потом сама высвобождает память по мере необходимости.

Немного статистики...
Если файловое кеширование у меня занимало примерно 300 мегабайт на HDD, то memcached кеширование занимает всего 150 мегабайт памяти.
Если не использовать кеширование вообще, то есть использовать только родное DLE'шное, то MySQL жрал у меня 50% CPU на сервере при посещаемости 100 тыс уников в сутки. А с использованием кеширования будь то файловое или memcached, MySQL жрет не более 10% CPU. Сказка не правда ли? При всем при этом я использую время жизни кеша всего 2 часа.

Ну и на последок... Для оценки эффективности работы memcached можно использовать скрипт приведенный во вложении.
Юзайте на здоровье

 

[Sudba]

Ну что же сайт заблокировали из-за большой нагрузки. Вот статистика, может поможет решить мою проблему:
Вот статистика может чем поможет объяснить мою нагрузку

_http://radikal.ru/F/s017.radikal.ru/i422/1110/45/c4b3fab74e30.jpg.html

 

[Горбушка]

Честно, не читал всю тему...

Отвечу как хостер:
1) 404 ошибка НЕ грузит сервер. Серверу без разницы - отдать файл или 404 ошибку.
2) Чистка аккаунтов - это разовая нагрузка (при нормальной реализации) не грузи сервер.
3) Может грузить сжатие. Если трафик безлимитный - отлючите.
4) Как я понял, посещалка большая - берите vds, заплатите хорошему админу 2к рублей за установку и настройку и забудьте о воплях хостера. VDS превышать ресурсы не умеет.

 

[Sudba]

Вот мне выдал хостер информацию

Общее количество запросов составляет 19467.
Наиболее частые обращения идут со следующих IP:
1132 188.24.237.32
589 87.250.252.242
366 109.184.36.26
363 91.197.128.216
340 77.121.98.240
328 66.249.72.187
242 85.26.165.40
237 67.195.115.233
233 157.55.116.22
225 95.26.95.169
200 79.246.124.227
172 87.252.227.84
154 184.105.162.190
152 178.45.146.218
145 95.26.167.210
145 188.163.88.142
142 93.80.228.234
130 213.109.12.239
129 206.63.230.214
126 95.25.232.57
126 82.155.64.60
107 95.25.124.102
105 95.24.39.54
105 85.238.108.121

Также приводим статистику по наиболее часто запрашиваемым скриптам:

13 /engine/engine.php
29 /engine/opensearch.php
278 /engine/classes/min/index.php
835 /engine/modules/antibot.php (это сапа)
1378 /index.php

информация за 2 суток

 

[-=ZorG=-]

Школота ддосит?)

 

[Sudba]

Не думаю, по крайней мере надеюсь))) Такая фигня месяц уже)))

 

[-=ZorG=-]

логи в студию с запросами от етих айпи.

 

[Sudba]

я заблокировал их. поэтому логи больше не ведутся)))

 

[lift]

Sudba как это на нагрузке сказалось?

 

[Ernest]

По нагрузке, был сайт с кучей модулей на 7.3 работал нормально (база 5к юзеров и 50к новостей) кол-во запросов никогда не волновало, нагрузку держал, хостер не жаловался, решил перенести его на 9.4 UTF обновлять базу стал повис сервак сутки сайты были не доступны, решил перенести его на:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

обновил до 9.4 UTF восстановил базу, но модули практически никакие не стал ставить, отключил все что можно, включил кэширование, но нагрузка по прежнему серьезная:

Для просмотра скрытого содержимого вы должны войти или зарегистрироваться.

что может быть не так или 9.4 намного прожорливее?
Иногда админка 9 секунд грузится (сейчас 5,03793 открывалась)