- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Как удалить плохие SEO-ссылки и очистить ссылочную массу сайта
Применяем отклонение ссылок
Сервис Rookee

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Добрый вечер.
Попробовал обкатать на днях на базе 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"