Веб-разработка

индекс
236,88

Нагрузочное тестирование и тюнинг популярных веб-приложений

Мы проводим нагрузочное тестирование для распространенных CMS и веб-приложений. Сейчас это Drupal, Joomla, Wordpress, phpBB и SMF. Результаты тестирования будут публиковаться открыто.

Приглашаю принять участие в тестировании. В обмен участники получат бесплатно годовой хостинг на VDS.


Цели тестирования

Главная цель: определить какую посещаемость могут обеспечить заданные аппаратные конфигурации. Или, в обратной формулировке, сколько серверных ресурсов нужно для обеспечения заданной посещаемости. Дополнительная цель: найти распространенные узкие места, характерные для приложения, чтобы составить общие рекомендации по настройке и оптимизации.

Методика тестирования

Чтобы получить осмысленный результат, а не сферического коня в вакууме, тестирование нужно проводить в максимально реалистичных условиях. Для этого требуются уже существующие сайты — с сложной структурой, с контентом, с подключеными дополнительными модулями и т.д. В идеале нужно несколько сайтов разной сложности и тяжести.

С тестируемого сайта снимается копия, которая размещается на тестовых серверах разной мощности (виртуальные машины Xen). На работе оригинального сайта это никак не сказывается, он продолжает работать как прежде.

Тестирование выполняется одновременным обращением с нескольких машин с помощью программы siege, которая прогонятеся в цикле по составленному списку запросов. Список запросов для siege формируется либо из лог-файлов веб-сервера оригинально сайта, либо по логу, полученному рекурсивным обходом сайта с помощью wget. Совсем замечательно было бы, если в тестировании еще были реализованы сценарии с авторизацией и POST-запросами.

Во время теста также замеряется объем используемой памяти, число процессов, потребление процессора и памяти по процессами, дисковый ввод-вывод.

Результаты тестов анализируются, производятся новые настройки и тестирование продолжается до достижения устойчивых результатов.

С нашей стороны обеспечиваются необходимые для тестирования аппаратные ресурсы, установка операционной системы, помощь в разворачивании тестируемых сайтов, настройка инструментов для тестирования и помощь при самом тестировании, помощь в анализе результатов тестирования, помощь в тюнинге операционной системы и программного обеспечения.

Пожелания к участникам

Обязательно требуется хорошее знание языка программирования и базы данных, с помощью которых реализовано тестируемое приложение, и достаточное понимание устройства приложения. Тестирование может потребовать от участников заметных затрат времени, поэтому, пожалуйста, трезво оцените возможность своего участия.

Пожелания к сайтам участников

Сайты не должны нарушать российские и международный законы, это не должен быть поисковый спам, финансовые пирамиды и прочие «серые» проекты. Желательно, чтобы это были общественно-полезные сайты, но вполне могут быть и коммерческие сайты.

Конфиденциальность данных

Мы относимся к тестируемым сайтам так же, как к серверам обычных платных клиентов. Мы являемся оператором связи и гарантируем конфиденциальность информации на стандартных условиях, которые регулируются Законом о связи. При необходимости, соглашение о конфиденциальности может быть оформлено в виде договора на бумаге.

Бесплатные VDS для участников тестирования

Квота на бесплатные VDS для участников тестирования: 30 серверов сроком на 1 год. Характеристики серверов: виртуальная машина Xen, 480 MHz CPU, 256 Mb RAM, 8 Gb HDD. Можно будет предоставить сервер и большей мощности, но это нужно обсуждать отдельно. Число участников тестирования не ограничено только тридцатью, и если вам не нужен бесплатный VDS, вы тоже можете принять участие в тестировании.

Сроки

Тестирование начнется, ориентировочно, 20 июня. Максимальный срок тестирования — месяц, минимальный — как получится. Для тестирования будет предоставлено до 120 VDS различной мощности — от 160 MHz CPU/64 Mb RAM/2 Gb HDD до 2560 MHz CPU/2048 Mb RAM/64 Gb HDD.

Принять участие

Заявки на участие в тестировании принимаются через форму на сайте: www.truevds.ru/contacts.form В заявке нужно будет написать «Тестирование $appname», где $appname — название тестируемого приложенияи, и там же дать ссылки на свои сайты, на нем работающие. Вопросы и пожелания лучше всего обсуждать здесь.

P.S. Если вы сами не будете участвовать в тестировании, но у вас есть знакомые, которым это могло бы быть интересно, дайте, пожалуйста, им ссылку на этот пост.

UPD. Тестирование не ограничивается этими 5 приложениями, вы можете предлагать другие варианты. Главное, чтобы это был популярный open-source продукт.
+35
12 июня 2009, 00:10
32

комментарии (63)

+6
posthuman #
Замечательная идея. Надеюсь результаты вы опубликуете.
Кстати на мой взгляд, именно подобный тест нужно использовать в оценке вебстудий — тестирование созданых ими сайтов на нагрузку и секюрити.
+1
sply #
Обязательно будут опубикованы.
0
sply #
Для оценивания сайтов веб-студий овичнка выделки не стоит. Такое тестирование все-таки дорогое удовольствие. Для массового продукта результат тестирования смогут использовать много народу. А сайты студий — только для десятка потенциальных клиентов.
0
rinat_crone #
Скорее всего имелись ввиду сайты, которые созданы студиями для клиентов. Это могут быть и сложные, нагруженные сайты.
0
posthuman #
Именно.
+2
zw0rk #
Глупо. 99% сайтов создаются без учета возможных нагрузок, соотв. в бюджеты и в сроки не закладывают оптимизации, возможность легко масштабировать проект и т.п. и т.д.

Это всё равно как все выпускаемые авто тестироавть на проходимость по дорогам Якутии. Порш, например, не осилит.
0
zw0rk #
> сайтов создаются без учета возможных нагрузок

без учета высоких нагрузок, конечно же
0
Eugene007 #
А можно ли в это тестирование добавить CMS eZPublish?
0
sply #
Напишите заявку. Если 20-му будут свободные места, сделаем и для ezpublish.
+5
vp7 #
Мне кажется, что всё-равно получится только сферический конь в вакууме :(
На разных сайтах используется совершенно разный набор плагинов и они могут кардинально влиять на производительность.

Как в итоге свести всё в единую таблицу — не представляю.
Максимум что можно получить на выходе, это табличку, где по каждому тестируемому сайту будет указан набор используемых плагинов (а также объём данных в БД) и итоговая производительность.

И вполне возможно в таблице окажется в одной строке Джумла с производительностью 100 хитов/сек, а в другой — 2 хита/сек. Ибо разные плагины.
0
sply #
Для комбинаций всех плагинов данные для точных прогнозов действительно не получить, тут уж ничего не сделать :(. Как компромисные вариант предполагается тестирование этого же сайта без плагинов, тестирование с отдельно включенными плагинами, чтобы можно было вынести их в отдельные коэффициенты. Но это уже если тестеры смогут так глубоко зарыться в процесс.

С другой стороны, сейчас нет вообще никаких достаточно конкретных и вопроизводимых тестов даже по голым системам. На безрыбье пригодятся и результаты с точностью до порядка.

Когда на форуме видишь где-нибудь вопрос «какой нужен сервер для сайта на Drupal c 30 000 хитов в сутки» и видишь ответы, про за 5 баксов в месяц или выделенные дуал ксеон, это похоже на разговор первобытных строителей, решающих, сколько кирпечей нужно для дома — сто или миллион.
+1
vp7 #
Могу предложить на тестирование сайт pspfaqs.ru/ с CMS под названием NGCMS.
Очень мало распространена, но достаточно шустрая.
Автор сайта готов предоставить свой бекап, настройкой и тестированием могу заняться я.
0
sply #
Посмотрел в яндексе, слишком мало людей ею интересуется. Давайте подождем 20-го, если будут свободные места, возьмем на тестирование и NGCMS. Вы пока заявку через форму напишите, чтобы у нас в общий список попала.
+1
Genius_A #
А еще и от версий сильно зависит.
В той же Joostina иной механизм кэширования.
От грамотности настройки зависит…
0
sply #
Да. Для этого и стараемся взять не по одному экземпляру, а с хотя бы какими-то вариациями. В идеале нужно, чтобы это были самые типовые конфигурации, но это уже как повезет с участниками.
НЛО прилетело и опубликовало эту надпись здесь
0
vp7 #
Так ведь предлагается запускать копию сайтов участников на специально выделенном тестовом стенде.
Поэтому на работу сайтов-оригиналов тестирование никак не повлияет.
–1
Genius_A #
А как тогда нагрузка будет эмулироваться?
Я так понял что как раз сами сайты предлагается переносить, с их посетителями…
0
fuCtor #
Перечитайте топик, там все написано. А конкретно раздел «Методика тестирования».
+3
vp7 #
Читай детально топик (автор топика — не я) :)
Нагрузка будет эмулироваться на основе анализа логов WEB сервера, при возможности — будет полностью эмулироваться цикл работы пользователя (залогинился, походил по страничкам и так далее).
0
vp7 #
Ой, не туда ответил.
Мой предыдущий пост — ответ на вопрос Genius_A.
НЛО прилетело и опубликовало эту надпись здесь
0
sply #
Такой вариант, к сожалению, совершенно не подойдет. Нужны популярные варианты, чтобы результаты тестирования приложения могли бы пригодиться другим.
НЛО прилетело и опубликовало эту надпись здесь
0
sply #
Нам нужны тесты, какую нагрузку держат именно стандартные движки.
0
Fanatik #
Можно уточнить, исследование проводится с целью оценить именно оборудование или оптимизированность/возможности CMS-ок: «какую посещаемость могут обеспечить заданные аппаратные конфигурации».

Мне например, думаю как и большинству здесь, более интересно та инфа которая будет говорить о таком спорном вопросе — какая из этих систем лучше.
0
sply #
Основная цель именно оценить какие кому могут понадобиться ресурсы.

Если попадутся тестовые сайты без плагинов и с примерно одинаковым кол-вом материалов, да, побочным эффектом будет сравнение производительности CMS. Достаточно будет посмотреть какую посещаемость они будут обеспечивать на одинаковых аппаратных конфигурациях.

+2
GmasteR #
А можно MODx включить в тест?
Спасибо
0
sply #
Давайте подождем 20-го, если будут свободные места и будут сайты на MODx, возьмем.
0
mstarrr #
Бестолковая идея имхо сравнивать кенгуру с бараном по той лишь причине, что они кушают траву.

Показатели на выходе можно подогнать под любую ЦМС, зная слабые и сильные места. В зависимости от разного железа, размера базы, активности юзеров на сайте показатели на выходе по производительности нельзя сравнить.
0
sply #
Бестолковое сравнение — когда нужно оценить размеры пастбища, то сколько жрут травы кенгуру и бараны очень имеет значение.

Если можно будет так легко манипулировать показателями на выходе, значит это будут хорошии инструкции по тюнингу. Которые будут полезны не меньше, чем сама оценка производительности.
0
mstarrr #
Смысла сравнивать барана с кенгуру никакого нету по многим причинам, основная из которых — нельзя получить адекватный результат после тестирования.

Скажите, какой результат вы планиурете получить и что он даст пользователям?

Очень часто хостеры пытаются «анализировать» софт и давать советы, но такие тесты чаще всего ничем и заканчиваются.

Лучшая цмс — эта та, в которой разбирается програмист заказчика и дешевле на выходе по поддержке и хостингу.
+1
sply #
Цитата из текста
— Главная цель: определить какую посещаемость могут обеспечить заданные аппаратные конфигурации. Или, в обратной формулировке, сколько серверных ресурсов нужно для обеспечения заданной посещаемости.
— Что даст пользователю — ответ на вопрос, который несколько раз в день задают на разных форумах: «какой сервер (какие ресурсы) требуется для сайта на Drupal c 30 000 хитов в сутки?»
0
mstarrr #
Скажите честно, вы вытались найти аналогичные тесты в сети? Может до вас уже кто-то делал эту работу?

И если искали, почему не привели свои аргументы, почему ваш тест будет успешным? Что в нем будет нового и почему ему нужно будет верить?
0
sply #
Нормальных тестов нет. Есть кони в вакууме — на большой мощный сервер ставятся дефолтные инсталляции и прогоняется ab на первую страницу пустого сайта.

На shared-хостинге, понятно, таких тестов не может быть в принципе. Есть кучу соседей по серверу, есть особенности настройки и выделения ресурсов у каждого хостера.

Для указанных целей тестов не было вообще.
0
sply #
Цитата из текста:
Главная цель: определить какую посещаемость могут обеспечить заданные аппаратные конфигурации. Или, в обратной формулировке, сколько серверных ресурсов нужно для обеспечения заданной посещаемости.

Что даст пользователю — ответ на вопрос, который несколько раз в день задают на разных форумах: «какой сервер (какие ресурсы) требуется для сайта на Drupal c 30 000 хитов в сутки?»
НЛО прилетело и опубликовало эту надпись здесь
0
mstarrr #
Еще как вариант: цвет глаз :)

Только как уже говорили выше — на параметры выбора полянки для выпоса это мало влияет.

Естественно — чем качественнее трава — тем лучше будет мясо.
0
mist #
Готов отдать на растерзание — goths.ru
Там стоит — ipb, smarty, mediawiki.
НЛО прилетело и опубликовало эту надпись здесь
0
mist #
smarty через API к ipb — выдаёт морду сайта и некоторые страницы. вроде фотографий, афиши, пользователей по городам.
+1
Shing #
Еще бы livestreet и другие аналогичные движки погонять.
0
edneo #
И bigstreet бы.
0
edneo #
Особенно заостряю на него внимание. :)
0
kikaha #
я взял тариф True22 под livestreet, как ns-ы обновятся — кину урл проекта, пока всё устраивает, перед официальным запуском конечно попробую стресс-тест
0
kikaha #
в общем, как себя чувствует livestreet на vds, сказать тяжело — пока что тупо не запускается (при выделенных 128M memory limit — phpinfo тут: beermania.com.ua/test.php)
0
sply #
Вероятно, xcache глючит.
94.127.66.9/
94.127.66.9/phpinfo.php
0
kikaha #
удалил xcache. рестарт. фефект тот же (
0
sply #
тогда попробовать по очереди другие лимиты памяти (16 Mb, 512 Mb), другие версии livestreet, php без suhoshin, другую версию php
0
kikaha #
менять версию php (без suhosin) я не стал, с памятью наигрался вволю, поставил даже memory_limit=-1 (без ограничений), чем поверг апач в глубокую задумчивость, с параметрами php.ini вообще как Мамай — рубил и косил без разбору в разных комбинациях

… в общем, с 3-й версией livestreet результат нулевой (сборка Ubuntu 8.04 + Apache2 +php5.2)

скопировал с рабочего сервера настроенную версию livestreet 0.2 — запустилась нормально, провел предварительный нагрузочный тест (через loadimpact.com) — запустил тест на виртуальном хостинге на hqhost.net, а потом на vds.
Результаты практически идентичны (хотя и жуткие, но это уже беда самого скрипта), надо увеличить нагрузку, хотя боюсь для данного конкретного livestreet больше 50 человек одновременно — уже летально, я лично редко жду более 20 секунд загрузки страницы.
0
sply #
10 запросов одновременно — это гораздо больше, чем 10 человек, ходящих по сайту и читающих страницы. Так что со скриптом ничего фатального.

Кстати, у меня релизная 0.3 на Ubuntu 8.04 тоже поднялась без проблем: 94.127.66.8/, 94.127.66.8/phpinfo.php
0
kikaha #
не затруднит список пакетов при инсталляции привести и если были доп. настройки php — то и их тоже? буду очень благода :))

имхо, грабли в моих настройках, чую, но обосновать не могу. и, да, у меня не чистый livestreet, на него навешен плагин для корпоративных блогов — и на 3-ю версию я его накатывал, и на текущей… так что сравниваем мы 2 не совсем одинаковые системы, сорри, сразу забыл сказать
0
sply #
М.б. в плагине синий цикл при каких-то условиях возникает.

Пресет «Минимальная инсталляция Ubuntu 8.04», через aptitude: wget, unzip, apache2, libapache2-mod-php5, mysql-server, php5-mysql с зависимостями, без доп. настроек. Потом wget sunet.dl.sourceforge.net/sourceforge/livestreet/LiveStreet_0.3.1.zip; unzip LiveStreet_0.3.1.zip; создать базу (в utf8); mysql -uroot -p ls < sql.sql; vi config/config.db.php; chmod 0777 uploads logs/ templates/compiled/ templates/cache/; rm index.html
И открывается страница livestreet

0
kikaha #
ок, ситуация прояснилась, спасибо.
в общем и целом пока сервисом доволен, ждем админки для пользователей… и управления для днс-сервера, все-таки неудобно письмами днс заказывать
+2
REDbyte #
Не знаю, по мне так затея хорошая, очень редко когда получается найти в документации системные требования на клиента. Поэтому планирование мощностей железа проектируемого проекта превращается в гадание на кофейной гуще с поправками на собственный богатый опыт топтания граблей…
0
xzirrow #
Понравилась ваша фраза :) «гадание на кофейной гуще с поправками на собственный богатый опыт топтания граблей… » — однозначно в избранное.
+1
xzirrow #
Нет ли идеи в обозримом будущем провести такое же тестирование не opensource проектов? а проприетарных рунетовских (разрабатываемых и продаваемых в России)
Bitrix, NetCat, UMI, ABO?

И клиенты будут знать какие же железные ресурсы нужны для этих продуктов… Потому что из их рекламы явно это не следует совершенно. Вопрос такой (про нагрузочное тестирование именно проприетарных продуктов) возник потому что если смотреть на рейтинг Теглайна 2009 (тьфу-тьфу не к ночи он будь помянут) то Open Source продуктами в Рунете пользуется ой как мало студий.
0
sply #
Желание было, но есть сложности, которые не понятно как решать.

1. Тестирование нужно проводить на реальных сайтах. Для того, чтобы владельцы согласились участвовать своими сайтами в тестировании, их нужно чем-то заинтересовать. Годовой хостинг им не нужен.

2. Для тестирования нужны люди. Те люди, которым владельцы сайта доверили бы работать со своими данными. А делать все только своими силами было бы не очень интересно нам, т.к. много других задач.

Наверное, тут можно придумать какие-то решения, но пока даже не думается в эту сторону.
0
the_ghost #
Отписал на почту, что могу предоставить и развернуть большой сайт на Textpattern — около 600 статей, картинки, плагины и т.п. штуки.
0
alkosasha #
а пробовали протестировать на чем-то из своего, написанного на ror? к примеру на mywishlist? есть какие-то результаты?
0
sply #
Фреймворки на нагрузку бесполезно тестировать. Она ведь зависит не столько от них, сколько от того, что с их помощью написано. Тот же mywishlist раз пять подвергался небольшим по изменению кол-ва кода оптимизациям, и после устранения очередного боттлнека начинал есть ресурсов в несколько раз меньше, чем до вмешательства. На VDS он все-равно не помещается :)

Хотя ror сейчас у нас тоже тестируется — groups.google.com/group/ror-truevds
Только задача там другая — отшлифовать пресет RoR production, чтобы была удобная и быстродействующая среда для RoR приложений на VDS.

0
vp7 #
Было ли в итоге проведено тестирование?
И если да, то хочется посмотреть на результаты (ведь это не закрытая информация?)
0
Maklaut #
Поддержу вопрос. Хотелось бы увидеть результаты тестирования.
Особенно интересует вопрос удалось ли на основе файлов access.log и рекрусивного обхода wget-ом получить реальные сценарии для нагрузочного тестирования?
Программа siege использует куки для сохранения сессии? Если да, то тогда каким образом строились «цепочки» страниц по которым «ходили» виртуальные пользователи во время тестирования?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.