я бы не сказал плохой, скорее стандартный. Здесь сталкивается желание владельца выжать из оборудования максимум, зачем хостеру, чтоб процессор простаивал, поэтому проще добавить больше пользователей и сайтов, другое дело если это вип клиент, для такого можно отдельно и VPS поднять и помочь ему настроить. На счет того, что и на shared хостинге тоже может быть все хорошо настроено - не спорю, но это нужен грамотный настройщик. Или есть универсальный способ грамотной настройки?
К сожалению таких данных пока не могу выложить. Модуль стоит на нескольких моих продакшн-системах, но с них данных я публиковать не могу, разве что графики. Кстати постараюсь консолидировать накопленную информацию по модулю и следующей статьей выложить рекомендации по использованию и примеры использования, методы анализа, а также обновленный интерфейс и дополненный функционал.
Ну если статистика неинтересна, то никто силой не заставляет ее вешать.
Насчет БД — у каждой конторы свой подход к написанию ПО.
И опять же повторюсь — если отсутствие буфиризации окажется узким местом, то сделаю ее. Просто буферизация порождает другую проблему — увеличение использования памяти модулем(точнее демоном), этот вопрос нужно аккуратно решать.
Ну не стоит сразу ярлыки вешать. Давайте тогда его нейтральным назовем :). И никто не говорит «Ставьте обработку на все запросы!!!». Я вообще не рекомендую на обработку статического контента его настраивать. Потому как статика не приносит много проблем. ИМХО его будет полезно использовать для вычисления проблемного хоста или еще точнее скрипта. Я вижу тенденцию, что сейчас стала очень актуальна тема — лимитирование ресурсов отдельного сайта, а также мониторинг.
И я не говорю категоричного нет буферизации — если ее отсутсвтие в самом модуле окажется проблемным местом — допишу и ее. Проект-то развиается.
Сохраняет в базу на каждый запрос. Буферизация — это дело самой базы данных. Буферизация запрасов — это на 0.3 веху, когда модуль по сети данные гонять начнет. А для локальной версии — смысла в этом не вижу. ИМХО база и сама неплохо с этим(буферизация) справится.
Немногочисленные тесты выложил лишь с одной целью — непосредственно на цифрах продемонстировать, что модуль на сам запрос фактически не влияет, т.к. в самом запросе кроме считывания CPU данных и посылки этой информации демону ничего не делает. Причем от mod_performanсe ожидается минимальное влияние на запрос, даже если демон по како-то причине не может принять данные. Вот другой вопрос сам демон — он может грузить систему, но исследование его деятельности я оставлю на следующую статью. К тому же я б был благодарен, если будут находится желающие потестирвать, к тому же для этих целей специально поднята система поддержки на сайте модуля. Если обнаружите баг или аномалии — пишите.
Фильтр запросов — это обычный regexp, который подчиняется всем правилам регулярных выражений. Если нужны конкретные файлы php, то PerformanceScript — он именно выполняющийся скрипт проверяет
Ну не судите строго — это просто пример. Я думаю каждый на своем сервере докрутит как безопаснее. Я у себя SQLite использую, т.к. сервер не сильно загружен, поэтому пока боков с базой нет. Более 3Мб не разрасталась.
Не совсем понятен вопрос. Сейчас модуль так и работает — одна часть посылает данные от апач(только не через UDP, а через сокет) отдельному демону, который и пишет в БД. А вот какая база — здесь можно выбрать SQLite, MySQL, Postgresql или вообще в лог. Демон может коннектится к любой. Или что-то другое имеется ввиду? А если имеется ввиду посылка статистики по сети на какую-то отдельную машину, например централизированный сервер хранения статистики, так это в планах. Т.к. такая задача предусматривает множество подзадач типа шифрование пересылаемых данных, постановка запросов в очередь при перегрузке централизированного сервера и т.д. Это планируется на 0.3 веху. Не все же сразу. Пока локальная модель.
Абсолютно верное замечание, но на такой случай в модуле имеется подрезание истории. Т.е. мне на практике более 30 дней истории не требовалось. Поэтому демон каждые три часа проводит сканирование базы и удаляет старые записи. А по поводу интенсивной нагрузки и базы SQLite, я выложил 0.2 версию модуля, где имеется возможность сохранять по выбору: 1) в текстовый лог(с заданным форматом); 2) SQLite базу и 3) MySQL база данных. Т.е для неинтенсивных серверов можно использовать SQLite, а для более нагруженных MySQL или лог. Плюс еще в новой версии модуля организована поддержка Apache+mod_ruid2(это был первый шажок в поддержке безопасного запуска скриптов сайта). Насчет соединений: при каждом запросе происходит подключение к демону через unix-сокет, по окончанию обработки запроса соединение разрывается.
По поводу доработанного модуля я готовлю новую статью, где постараюсь прикрепить исследование нагрузки на сервер при подключении модуля, но быстро ее подготовить не получается :(. Если кто захочет модуль протестировать и обнаружит баги пишите — на сайте модуля организована поддержка :)
ab использовал пока что только в тестах на стрессоустойчивость. А вот временные характеристики пока не снимал — каюсь. Но обещаю все это проделать, как доведу его до состояния «конфетки» :)
Ну как бы на производительность отдельного сайта он особо не влияет, т.к. все что делает модуль по запросу — это только через сокет демону посылает необходимые сведения, на этом все, запрос далее выполняется как обычно. А вот на сервер вцелом по IO может нагрузка увеличиться из-за того, что демон после прекращения запроса будет записывать данные в базу. На текущий момент модуль может обрабатывать одновременно ограниченное чило запросов, при достижении предела он прекращает прием новых а просто занимается завершением обработки уже принятых, но при каждом запросе сверх лимита, он сообщает в лог сервера, о том, что текущего лимита по одновременной обработке не хватает и просит увеличить число. На те запросы, которые не могут быть обработаны демоном это никак не влияет, они выполняются как и обычно, но просто не отслеживаются.
Да. Здесь вы правы насчет возможности логирования еще и в лог(опциональный выбор). Насчет анализатора, впринципе, я и хочу написать, что-то наподобие phpmyadmin, который будет разбирать накопленную информацию. Но определенный функционал по анализу, все же хочу в модуле оставить, чтоб после минимальной установки у пользователя уже была возможность анализировать, а потом по его желанию, если он хочет — то ставит дополнительные скрипты анализа.
я бы не сказал плохой, скорее стандартный. Здесь сталкивается желание владельца выжать из оборудования максимум, зачем хостеру, чтоб процессор простаивал, поэтому проще добавить больше пользователей и сайтов, другое дело если это вип клиент, для такого можно отдельно и VPS поднять и помочь ему настроить. На счет того, что и на shared хостинге тоже может быть все хорошо настроено - не спорю, но это нужен грамотный настройщик. Или есть универсальный способ грамотной настройки?
да, я планирую сделать реквест в апстрим
Насчет БД — у каждой конторы свой подход к написанию ПО.
И опять же повторюсь — если отсутствие буфиризации окажется узким местом, то сделаю ее. Просто буферизация порождает другую проблему — увеличение использования памяти модулем(точнее демоном), этот вопрос нужно аккуратно решать.
И я не говорю категоричного нет буферизации — если ее отсутсвтие в самом модуле окажется проблемным местом — допишу и ее. Проект-то развиается.
Немногочисленные тесты выложил лишь с одной целью — непосредственно на цифрах продемонстировать, что модуль на сам запрос фактически не влияет, т.к. в самом запросе кроме считывания CPU данных и посылки этой информации демону ничего не делает. Причем от mod_performanсe ожидается минимальное влияние на запрос, даже если демон по како-то причине не может принять данные. Вот другой вопрос сам демон — он может грузить систему, но исследование его деятельности я оставлю на следующую статью. К тому же я б был благодарен, если будут находится желающие потестирвать, к тому же для этих целей специально поднята система поддержки на сайте модуля. Если обнаружите баг или аномалии — пишите.
По поводу доработанного модуля я готовлю новую статью, где постараюсь прикрепить исследование нагрузки на сервер при подключении модуля, но быстро ее подготовить не получается :(. Если кто захочет модуль протестировать и обнаружит баги пишите — на сайте модуля организована поддержка :)