Как стать автором
Обновить

Комментарии 63

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Естественно — чем качественнее трава — тем лучше будет мясо.
Готов отдать на растерзание — goths.ru
Там стоит — ipb, smarty, mediawiki.
НЛО прилетело и опубликовало эту надпись здесь
smarty через API к ipb — выдаёт морду сайта и некоторые страницы. вроде фотографий, афиши, пользователей по городам.
Еще бы livestreet и другие аналогичные движки погонять.
И bigstreet бы.
Особенно заостряю на него внимание. :)
я взял тариф True22 под livestreet, как ns-ы обновятся — кину урл проекта, пока всё устраивает, перед официальным запуском конечно попробую стресс-тест
в общем, как себя чувствует livestreet на vds, сказать тяжело — пока что тупо не запускается (при выделенных 128M memory limit — phpinfo тут: beermania.com.ua/test.php)
удалил xcache. рестарт. фефект тот же (
тогда попробовать по очереди другие лимиты памяти (16 Mb, 512 Mb), другие версии livestreet, php без suhoshin, другую версию php
менять версию 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 секунд загрузки страницы.
10 запросов одновременно — это гораздо больше, чем 10 человек, ходящих по сайту и читающих страницы. Так что со скриптом ничего фатального.

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

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

Пресет «Минимальная инсталляция 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

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

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

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

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

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

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

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