Интересный способ для разруливания лимитов на форумах

K
На сайте с 24.03.2004
Offline
223
771

Добрый вечер.

Попробовал обкатать на днях на базе SMF и MySQL 5.x, полет нормальный, к шаловливым ручкам устойчиво. Раньше подобное реализовывал в надстройке выше, на базе какого-то http proxy с добавленной возможностью ограничения запросов на базе каких-то полей из хидеров.

Не буду вдаваться в организацию хостинга, а расскажу о том, как можно использовать "Limiting Account Resources" от MySQL для практически любого форума. Само собой решение подходит для тех у кого свой сервер или какая-то VPS.

Перечь манипуляций:

Перекоцываем форум так, что бы пользователей он заводил не только в своих таблицах, а еще и среди пользователей mysql. Само собой заводимым пользователям должны выдавались гранты на нужную БД форума + устанавливались лимиты (http://dev.mysql.com/doc/refman/5.1/en/user-resources.html).

WITH MAX_QUERIES_PER_HOUR

MAX_UPDATES_PER_HOUR

MAX_CONNECTIONS_PER_HOUR

MAX_USER_CONNECTIONS

Для "гостей", т.е. не для авторизованных, заводим какого-то пользователя, типа guest, с которым проходит коннект к СУБД по дефолту. Процесс авторизации можно делать на свой вкус, в частности у меня реализован обработчик ошибок от MySQL и в случаях с запретом конекта по разным причинам пользователю выдается отлуп с соответствующей табличкой... ну а далее, если не прокатило, то конект от гостя и выводится чего выводится.

Вариант 2:

Если охота совсем основательно поковыряться, то выделяем определенное количество узких мест... всякие там подсчеты количества постов и т.д. и т.п., разделяем легкие и тяжелые поисковые запросы... хорошо если есть возможность сделать бенчмарк на определенные кусочки форума (да и не только) и выявить конкретно тот момент, после которого запросы начинают скапливаться в processlist... заметно визуально, большая точность не нужна.

Потом, конкретно под эту функциональность, заводим отдельного пользователя в mysql, которому ограничиваем конкретно то что мешает нам жить. Соответственно коннект/дисконект делаем как раз по краям.

Почему такое решение мне нравится больше, чем реализация какого-то механизма на базе shared memory:

- стоимость соединения с mysql очень маленькая

- механизм уже реализован в СУБД

- ограничения работают более точно

- можно реализовать гарантированный лимит + превышение

- не надо думать про dead lock's

- из скрипта всеравно надо соединяться с базой, но, к примеру, из search.php будет соединяться под forum_search, что само по себе освобождает нас от реализации защитных механизмов

- такое решение подходит для вариантов с большим количеством веб-серверов & single mysql, т.к. на уровне приложений нельзя сделать дешевый механизм для ограничения нагрузки на конкретные механизмы...

PS. Да, кстати, если по существу, то этим можно спасти Битрикс, в частности вынести какую-то функциональность на отдельные конекты, в случаях с VPS и добавить обработку ошибки "сервер is busy плиз трай эгейн later"

проверенная ддос защита (http://ddos-protection.ru) -> http://ddos-protection.ru (http://ddos-protection.ru), бесплатный тест, цена от размера атаки не зависит.

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий