Дополню так же тем, что тестить желательно полноценно. Производительность всегда определяется двумя параметрами: пропускная способность и время ответа. И при тесте производительности желательно смотреть на обе метрики.
Буквально этой ночью писал статью как тестировать базы данных с помощью jmeter, если кому-то интересно смотрите тут http://schiz.me/blog/2013/01/04/mysql-load-testing/. Все акутуально и для MS SQL, но нужно поставить соотв. драйвер.
Кроме того, как было замечено выше, индекс влияет на запись. Было бы здорово сравить тогда уж и производительность без и с индексом:)
Но ведь на самом деле никаких гарантий этого нет? Можно же построить отдельный метод, который просто будет рандомно с условием распределения выбирать длину повторений букв и в соотв. с этим законом выставлять знаки. На 100 символах скорее всего не проявится(в зависимости от закона), но стоит устремить кол-во подкидываний к бесконечности… Я тут же Вас разоблачу!
Кстати это отдельная нетривиальная задачка. Определить закон/порядок, если он есть.
Сначала смотрел на буквы Р, чтобы вычленить подряд идущие решки, и уже было подумал что подделали… Но потом решил посмотреть на буквы О, т.к. по сути они друг от друга ничем не отличаются. И вот судя по буквам О возможно последовательность не подделана:)
Можно сделать отедльные пакеты в репозитории, которые будут иметь набор кастомных метрик в виде шелл-скриптов. Тогда соотв, имея множество серверов нужно будет просто набрать sudo apt-get install zabbix-metric-harddisk и bash скрипты появтся в системе. Дальше нужно обновить конфиг агента, всего-лишь добавив вызов этого шел. скрипта, и длина вызова будет не большой. Ровно также метрики можно обновлять, и это будет на всем кластере.
Делаете отдельный пакет для MySQL, PHP, Oracle, Java App, обновляете на всем кластере, обновляете данные в морде заббикса. Вот и все.
>Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
В этом случае да, но hddtemp не генерирует событий. Мухи отдельно, котлеты отдельно. Если мне JVM скажет «МНЕ ПЛОХО», то да, такую метрику/событие лучше обрабатывать через zabbix_sender.
О боже! Товарищ! Это лишь дополнительная метрика! Давайте мы будем отделять мух от котлет! Метрики должны хранится в части системы мониторинга. И настройка в UserParameter наилучшее для этого место!
Я помню как занимался аналитикой СМ отдной фирмы. И когда там был такой винегрет, часть метрик в конфиге заббикса, часть где-то в кроне, часть где-то еще. Не делайте так, UserParameter был спецально для этого сделан.
Ну стоит определится чего именно хотите тестировать. «Виртуальными пользователями» как правило оперируют в scenario-based нагрузках. Это уже соотв. такие инструменты как apache jmeter, hp loadrunner, gatling tool. AB/siege/yandex-tank как правило необходимы именно для hit-based тестов.
Если нужна такая же морда, для отрисовки, то можно пользоваться BlazeMeter (платно) / Loadosophia (бесплатно) +JMeter.
Но сначала стоит определится как именно нужно нагрузить сервис, чтобы это отражало пользовательскую деятельность и то, что будет в реальности. Советую проконсультироваться с кем-то из нагрузочного тестирования. Можно и со мной, но это уже в личку. Буду рад ответить на любые вопросы. Не бойтесь, никаких прайсов высылать не буду:)
На самом деле не так сложно. Работая в разных фирмах я видел такие маленькие проекты. Вот например простой сайт perfload.ru/ от одного из парней Performance Lab. Там простая Joomla за которой стоит AB. А есть loadosophia.org от коллеги из Яндекса, но тут уже все хитрей. Это портал с хранилищем результатов. На лоадософии можно пользоваться своими разными генераторами нагрузки(ab, jmeter, yandex-tank), которые сами ставите рядом с обстреливаевым сервисом, а потом уже отчеты грузите на сайт.
Но скажу честно, подобные сервисы вроде loadimpact мало что дают в представлении нагрузочного тестирования. В жизни все сложнее. Даже если мы говорим про какой-то простой сайт с одинаковой информацией для всех пользователей, то все не так просто как кажется. Много разных урлов, которые нужно дергать, с разным распределением (одни ручки чаще, другие реже). Зачастую есть разница Connection: close vs Connection: keep-alive и нужно смотреть чем в осн. пользуются клиенты.
LoadImpact штука конечно хорошая, но даже потратив час на изучение ab/siege можно сделать больше и качественней своими силами. И даже построить красивые графики используя MS Office или loadosophia.org:)
Не понимаю, а чем это отличается от любых других кастомных метрик? Ну и кстати можно было бы сразу выложить xml-конфиг темплейтов? По кнопочкам тыкать не так удобно, а вставить xml-ку запросто, особенно учитывая тот факт, что различатся будет только UserParameter:)
Ну вот про BPEL, честно, ничего сказать не могу. В свое время мне предложили работу по данной тематике, но ушел в другое место. Кстати когда предлагали, условием было использование LoadRunner.
Просто использовать в Beanshell java фреймворк на самом деле не круто. Именно поэтому пришлось столько компилировать. Можно было бы сделать удобные ручки, скомпилировать их разок, т.е. фактически сделать обвязку и потом дергать их через beanshell. Но выбор за вами. Я бы на вашем месте писал полноценные семплеры.
>Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Тут нужно смотреть что за нити висели, и кто был виноват. Возможно даже одну JVM можно было потюнить до необходимого уровня производительности.
Поднять несколько JVM это простой уход от проблемы, а посмотреть что внутри JVM, вот это оказаться трудоемкой, но стоящей задачей=)
Буквально этой ночью писал статью как тестировать базы данных с помощью jmeter, если кому-то интересно смотрите тут http://schiz.me/blog/2013/01/04/mysql-load-testing/. Все акутуально и для MS SQL, но нужно поставить соотв. драйвер.
Кроме того, как было замечено выше, индекс влияет на запись. Было бы здорово сравить тогда уж и производительность без и с индексом:)
Кстати это отдельная нетривиальная задачка. Определить закон/порядок, если он есть.
Делаете отдельный пакет для MySQL, PHP, Oracle, Java App, обновляете на всем кластере, обновляете данные в морде заббикса. Вот и все.
>Однако, есть события, которые генерируются внешними сервисами, скриптами — и заниматься опросом или тем паче, отгребанием их в логах — не самая лучшая идея.
В этом случае да, но hddtemp не генерирует событий. Мухи отдельно, котлеты отдельно. Если мне JVM скажет «МНЕ ПЛОХО», то да, такую метрику/событие лучше обрабатывать через zabbix_sender.
Я помню как занимался аналитикой СМ отдной фирмы. И когда там был такой винегрет, часть метрик в конфиге заббикса, часть где-то в кроне, часть где-то еще. Не делайте так, UserParameter был спецально для этого сделан.
Если нужна такая же морда, для отрисовки, то можно пользоваться BlazeMeter (платно) / Loadosophia (бесплатно) +JMeter.
Но сначала стоит определится как именно нужно нагрузить сервис, чтобы это отражало пользовательскую деятельность и то, что будет в реальности. Советую проконсультироваться с кем-то из нагрузочного тестирования. Можно и со мной, но это уже в личку. Буду рад ответить на любые вопросы. Не бойтесь, никаких прайсов высылать не буду:)
Но скажу честно, подобные сервисы вроде loadimpact мало что дают в представлении нагрузочного тестирования. В жизни все сложнее. Даже если мы говорим про какой-то простой сайт с одинаковой информацией для всех пользователей, то все не так просто как кажется. Много разных урлов, которые нужно дергать, с разным распределением (одни ручки чаще, другие реже). Зачастую есть разница Connection: close vs Connection: keep-alive и нужно смотреть чем в осн. пользуются клиенты.
LoadImpact штука конечно хорошая, но даже потратив час на изучение ab/siege можно сделать больше и качественней своими силами. И даже построить красивые графики используя MS Office или loadosophia.org:)
Просто использовать в Beanshell java фреймворк на самом деле не круто. Именно поэтому пришлось столько компилировать. Можно было бы сделать удобные ручки, скомпилировать их разок, т.е. фактически сделать обвязку и потом дергать их через beanshell. Но выбор за вами. Я бы на вашем месте писал полноценные семплеры.
>Для нагрузочного тестирования уже приходилось пару раз подымать независимые jmeter, так как бывало что подвисали отдельные треды, несколько jmeter с меньшим количеством потоков работали хорошо.
Тут нужно смотреть что за нити висели, и кто был виноват. Возможно даже одну JVM можно было потюнить до необходимого уровня производительности.
Поднять несколько JVM это простой уход от проблемы, а посмотреть что внутри JVM, вот это оказаться трудоемкой, но стоящей задачей=)