Сайт якобы вызывает повышенную нагрузку на MySQL. Такую предъяву мне выдает мой хостер. Кто-нибудь сталкивался что Элеонор якобы перегружает мускул? Вообще на сайте постоянно находятся 30-40 гостей и это сайт СМИ. На этом хостере висят еще два сайта газет и один по посещениям превосходит мой, но выполнен на DLE. если что вот урл моего сайта: http://www.camonitor.com/

Нужно больше информации.. Поскольку нагрузка на базу по идее не может быть больше от нагрузки на сервер системой. Если найдется какая-то жутка неоптимальность - сделаю все возможное для ее исправления.

Alexander, может вопрос не в тему, но на что идёт ~12 запросов к базе?

azacgrus, а разве количество запросов как-то характеризует нагрузку на MySQL? Не верьте идиотам которые утверждают это! Так, например можно выполнить 100 запросов вида SELECT COUNT(`id`) FROM `table` - и это сожрет намного меньше ресурсов чем какой-то жутконеоптимизированный запрос.

Отвечая на Ваш вопрос., ядро системы делает 5 запросов:
1. Извлечение всех сервисов.
2. Удаление устаревших сессий пользователей.
3. Занос даной сессии в таблицу сессий.
4. Извлечение групп, в которых состоит пользователь.
5. Извлечение блоков, которые доступны пользователю.

По-моиму не много. Каждый из этих запросов выполняется за ~0.0001 сек. А все остальное - это уже запросы модулей. блоков, пользователей и опций.

Конечно же немного.
А у меня на сайте два своих блока - в нем по одному запросу. И стандартный новостной модуль news. Так что в сумме не намного больше.

А возможно ли отследить атаку, когда с одного IP адреса производятся многократные вызовы страниц через маленький промежуток времени? У меня есть подозрения что это атака.

Zzzhan, На тебя идет ддос атака, а не система перегружает базу.

Два явных признака ддос атаки постоянное число пользователей от 35 до 45 плюс при частом обновлении невозможность подключится к БД

Zzzhan, считаю что уместно делать ~20-30 не ресурсоемких запроса при генерации страницы. Остальное - кешировать!

Alexander, я задал этот вопрос после поста где-то на форуме 4дле, пост вида:

вот поэтому и задал свой запрос:)
====
нашёл ссылку, вот оригинал http://forum.4dle.ru/ipb.html?s=&showt...ost&p=46038
или

azacgrus, если мне укажут на неоптимальность в системе, конструктивно покритикуют относительно ее производительности - буду только благодарен. Людей, которые оценивают систему только с точки зрения количества запросов (без учета типа и "веса") я могу смело называть мудаками.

azacgrus, Везде хорошо где нас нету

Скорее всего это атака. Ничего особенного я в движок не добавлял, кроме переделанного блока категорий:

SELECT el_news_categories.id, el_news_categories_l.title FROM el_news_categories INNER JOIN el_news_categories_l ON el_news_categories.id = el_news_categories_l.id

и блока десятки новостей

SELECT el_news_l.id, el_news_l.title, el_news.reads FROM el_news INNER JOIN el_news_l ON (el_news_l.id=el_news.id) ORDER BY el_news.reads DESC LIMIT 0,10

Не думаю что эти запросы могли так сильно подвесить мускул хостера. Если до этого я предполагал, то теперь убежден полностью, что это атака. Поскольку не в первый раз, буду бороться.

Александр, вообще я был бы рад купить плагин защищающий сайт от многократного запроса с одного и того же IP. Для других движков я писал сам, а здесь хотелось бы чтобы он был родным. Хотя по идее эта опция должна быть бесплатной. В любом случае предложения - в личку.

Zzzhan, на PHP защищаться от атаки?? Не смешите. Может и есть для других скриптов, но это Свистелки и перделки

Разве не может помочь простая фильтрация по IP адресам, которая позволит отсекать слишком навязчивые запросы с одних и тех же адресов? У меня именно такая ситуация - гостей не более 30-40 и половина из них непрерывно дрочит по кнопке F5. Определить кто это делает по слишком короткому интервалу обращения и запретить доступ. Разве не будет работать?

Zzzhan посмотри скрипт http://avy.ru/ftopic1870.html, но на самом деле он действительно не поможет на 100% если это атака, хотя выдаст ИП с которых она идёт.

Запустил, работает, посмотрим что будет дальше ....

Я его использовал, но всё равно пришлось перейти к другому хостеру. Скрипт сдерживает самую малость потом падает.

Защищаться от атаки надо не PHP скриптами, а средствами настройки WebServera.

У Screatch правильно написано - Некоторые любят Saturn-Host, Jino, Seo-Host, а я люблю NetLevel

Кто ж виноват что хостер чайник и не может настроить сервер...

Короче.... Никакой не оптимальности в системе нет. Эта была атака и за последние сутки она достаточно хорошо отражалась предложенным kdv1978 скриптом.
Все более менее стабилизировалось... Скрипт успешно отсекает драчунов. Правда пришлось перенести капчу в отдельный файл, иначе в обычном варианте при обращении к странице происходит два последовательных запроса страницы index.php с одного IP адреса. В одном случае для загрузки самой страницы а в другом случае для генерации изображения капчи. Естественно что фильтр стал отсекать капчу. После переноса в отдельный отдельный файл все заработало. Этот файл captcha.php я создал по аналогии с upload, download со всеми проверками и загрузками классов, по идее безопасность не разрушил. В этот файл по гету передаётся id рисунка (id сессии) и имя капчи, то есть сделано так же как и в других модулях.