Foror, еще раз подумайте над задачей. Если у вас большая хеш-таблица, то возможно стоит не мучиться с железом, а взять несколько инстансов и поставить на них что-то вроде Cassandra.
Против руби аргументов нет. Ровно как и достойных инструментов на нем. На других же есть. Можете взять уже готовые решения, да на самом деле абсолютно любые, хоть ab или siege и сделать для них обертку на ruby в свой инструмент автоматизации тестирования. Но вы должны понимать, что руки у вас будут развязаны на столько, на сколько это разрешает инструмент. Любой фреймворк будет хуже проф. решений, по точности нагрузки, по фичам, по возможностям, стабильности и производительности работы. Хуже community. Я не думаю что этот список стоит продолжать. Выбор за вами. Если цель понять СЕЙЧАС тянем или нет, ну можете использовать фреймворк. Но что будете делать завтра, когда добавите новый функционал, который не вписывается в фреймворк? Что если упретесь в фреймворк? Вы уверены в нем? В стабильности, в точности? Если что-то сломается, есть community?
Я бы, все же, посоветовал не строить велосипеды, а воспользоваться профессиональными решениями для нагрузочного тестирования. В качестве нагрузочных приложений, посмотрите на или yandex-tank. В большинстве случаев, этими инструментами можно воспользоваться не написав вообще ни единой строчки кода.
>Весь фреймворк автоматизации реализован именно на нем.
Даже встроить что-то из apache jmeter или yandex-tank в свой фреймворк будет не так сложно как кажется, а в будущем избавит от ряда проблем, учитывая практически возможности этих инструментов.
Фреймворк для нагрузочного тестирования на ruby, уже, знаете ли, пахнет не хилым извращением=)
1. Да.
2. Скорее нет. Вы задаете общий период N секунд. Дальше iostat снимает данные каждую секунду в течении заданного периода N секунд (за вычетом 1 секунды, т.к. первый вывод iostat дает информацию за весь uptime). Дальше кладет данные за N-1 секунд в файл. Кладем, неагрегированные данные, хотя можно и агрегировать на самом деле.
3. На самом деле не обязательно. Период коллекции можно делать либо больше, либо меньше периода забора в zabbix. Делать период сбора коллекции больше, чем период забора в zabbix не имеет смысла, т.к. в zabbix будут просто подряд идти дублирующиеся значения. Смысла в них никакого, а база будет засираться ненужными данными. Если делать период коллекции меньше чем, период забора, то здесь нужно понимать, что тогда по этой метрике будет информация за время последнго цикла коллекции. Т.е., допустим коллекция раз в 15 сек. Забор 1 раз в минуту. Тогда, забор метрики будет за последние 15 сек. в течении прошлой минуты.
Ок, а зачем это вообще, и имеет ли смысл? На самом деле у нас метрик оч. много. На сайте описаны. У каждой может быть свой период сбора. Тогда какой выбрать для коллекции? Ну вот поэтому и оставил этот параметр для задания вручную.
4. Цикл на баше + sleep:)
Я специально разделил сущности. Есть скрипт iostat_collect.sh, есть iostat_parse.sh. Первый скрипт вызывается с одной периодичностью через метрику nomanlab.iostat.collect, и кладет в файл данные за заданный период. Все остальные метрики, обращаются к этому файлу со своими периодами через второй скрипт iostat_parse.sh. Это как раз и было сделано для того, чтобы можно было просто добавить первый скрипт в крон, отключить метрику nomanlab.iostat.collect, и ровно так же собирать данные. Причем, скрипт собирает данные за период, а дальше просто перезаписывает файл. Фактически, два скрипта работают асинхронно. А синхронно, как описано в шагах 1-2-3
to abbaerro:
>1. Работает какой-то скрипт (демон) или что-то в этом духе, который запускает «iostat -x n» и вывод записывает в файл.
>2. Работает какой-то ротатор, который этот файл очищает от старых данных (чтобы файл не разрастался).
>3. Каждые n секунд zabbix запрашивает данные из этого файла.
Дык сейчас скрипт работает, и перетирает файл. Это и есть ротация, только с периодом указанной дискретности. Зачем добавлять еще одну сущность? Когда приходит zabbix, он всегда получает инфу за последние 15 секунд. Зачем хранить остальные? Они ведь и так будут в zabbix.
Отчетливо предупреждаю, с помощью siege вы не сможете протестировать количество максимальных соединений. Только rps. Для коннектов, используйте лучше yandex-tank
Если необходимо протестировать именно коннекты, то желательно все же использовать в танке keep-alive соединения, и стрелять не rps, а наращивая сами инстансы. Максимальное кол-во можно определить только так. Задавайте по нему вопросы, если что-то не понятно, могу ответить прямо здесь. Касательно других инструментов, они все тоже стреляют rpsом, и фактически не могут протестировать на макс. кол-во одновременных http-сессий.
Ну и да, кстати. Если у вас зоопарк приличный, а мощностей самого заббикс сервера не много, то не советую использовать синхронное решение с увеличенным timeout. Воркеры заббикса будут простаивать. Лучше оформите скрипт в кроне (можете взять мою метрику выполнения, и просто добавить её в крон), а метрику, которая вызывает коллекцию данных, выключите. Так воркеры не будут простаивать=) Если есть еще вопросы — пишите, у меня есть опыт=)
Я тот товарищ с блога, который вы обсуждаете. Вообще, дисковая активность, в общем случае, имеет необычный характер нагрузки. Если вы просто включите iostat -x 1 100, и просто будете делать свои вещи, вы будете удивлены тому, как на самом деле загружены диски. В некоторые секунды они загружены полностью, а в некоторые простаивают. Именно поэтому я и собирал информацию с интервалом дискретности самого заббикса. Вообщем, снимайте с обычной для вас дискретностью заббикса (15 секунд, или сколько у вас там). Но используйте среднее значение за эти 15 секунд. iostat -x 1 2 выдает информацию, не отражающую реальность на самом деле. Как повезет с секундой. Может диск будет свободен, а может нагружен, и в заббиксе будет пила. Лучше потерять некоторую точность в предоставлении информации, но понимать, что на самом деле происходит на сервере. Если за 15 сек диск будет нагружен на 100%, заббикс не пропустит, не волнуйтесь=)
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
