О тестировании под нагрузкой
Oct. 23rd, 2009 01:30 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Задача — протестировать сайт на работу при большой нагрузке. Попробовали 2 способа:
Что делать?
- При помощи ab послали вагон запросов на какую-то одну страницу, попутно пытаясь пользоваться сайтом в обычном режиме,
- Посадили за компьютеры пару десятков юзеров и попросили их усиленно покликать по ссылкам.
Что делать?
no subject
Date: 2009-10-22 08:16 pm (UTC)2. (упрощенный вариант) Выкачивалка сайта. Пройдется по ссылкам. Запускаем с десятка юзерских мест, можно по несколько копий.
no subject
Date: 2009-10-23 02:25 am (UTC)Но бот, конечно - лучше, ещё лучше, если этот бот будет строить для себя структуру сайта и по ней некоторым образом ходить.
wget
Date: 2009-10-23 04:07 am (UTC)Re: wget
Date: 2009-10-23 05:18 am (UTC)Ну отлично :) Тогда в чём был вопрос?
no subject
Date: 2009-10-23 05:52 am (UTC)no subject
Date: 2009-10-23 04:03 am (UTC)no subject
Date: 2009-10-23 05:52 am (UTC)no subject
Date: 2009-10-24 08:28 am (UTC)и в гугле Web Stress Tools
вообще цель тестирования какая?? создать "пиковую нагрузку" и положить сервер?
или выяснить "при каких параметрах ложиться"?
Re: Цель тестирования
Date: 2009-10-24 08:41 am (UTC)подыхания, когда такие случатся.
Впрочем, насчёт причин торможения — есть инструмент, хоть и не очень
подробный: сам Catalyst (это такой перловый фреймворк для сайтов), . Уже с его
помощью удалось выявить одну из причин торможения: оказалось, шаблонизатор
Template Toolkit весьма неспешен.
Re: Цель тестирования
Date: 2009-10-24 03:38 pm (UTC)именно поэтому вместо XSLT я использую Blitz в php
ну переделы живучести если есть БД
замониторьте ее с помощью Cacti
в таком случае нагрузку через конфиги XML в pylot довольно просто эмулировать
еще есть всякие стресс утилитки которые "записывают действия пользователя" и потом проигрывают... в фоне через браузер в несколько потоков...