Выпустили пресс-релиз, в котором подвели итог нагрузочному тестированию продукта и всему циклу разработки между версией 5.0 и 6.0 направленному на увеличение производительности продукта.
6 000 000 страниц в сутки и быстрее на 80%, чем в 5.0 - это отличный результат! Реально, мы даже не смогли толком загрузить машину одним нагрузочным стендом и просто решили что 6 миллионов это уже отличный результат
Для версии Бизнес мы включили в отчет 1.6 миллиона хитов, но только потому, что сами себе поставили в ограничение время генерации страницы ниже 0.3 секунды. Но если посмотреть на график, мы выжали и 2 миллиона, но время генерации страницы уже выросло до 0.8 секунды (что, кстати, тоже отличный результат для такой нагрузки)
Я очень доволен технологией . Это большое достижение и очень помогает партнерам и клиентам.
Огромное достижение, что продукт в редакциях Старт, Стандарт, Малый бизнес может в режиме автокеширования даже не открывать соединение к базе данных, так как работает на ранее закешированных данных.
Большое спасибо ребятам из QSoft, большая работа проделана при проведении нагрузочного тестирования.
Спасибо Мастерхосту за выделенный сервер и терпение не отобрать его, пока мы собирались со временем.
+хотелось бы увидеть аналогичный тест на shared-хостинге ваших хостинг-партнеров
ровести нагрузочные тесты других CMS-ок мы, конечно, могли бы. Но кто даст гарантию, что мы все правильно настроим ... получиться как в недавнем "тестировании" удобства пользования, которые проводили "питерские коллеги".
Вот если бы поставщики других платформ согласились провести подобный тест, и сами бы подготовили свои сервера, а независимый эксперт "понагружал-бы". Но, нагрузочный тест – это очень трудоемкая и дорогостоящая работа (тестирование, которое мы здесь обсуждаем потребовало почти 4 месяца высококвалифицированных специалистов). Чтобы нормально подготовиться к такому "конкурсу" нужно иметь не одно тестирование за плечами и обладать достаточным опытом.
Думаю, реально другие CMS-ники вряд ли согласятся ввязаться в бой, так как понимают, что шансы близки к «0».
Хитрость в том, что большинство известных нагруженных проектов есть плод многолетнего шаманства, которое дало результаты в конкретном эксклюзивном случае. Сделать производительной «универсальную платформу» задача слишком дорогая.
У «CMS-ников» не хватает денег отказаться от прямых разработок сайтов (как Битрикс), а уж о подобных "длинных" инвестициях даже речи быть не может (тоже самое относится к безопасности, к системной работе по usability и т.д.)
А сравнение разных систем, оно доступно – посмотрите вокруг.
Вы знаете хоть один крупный (по-настоящему) проект на какой-нибудь CMS (кроме 1С-Битрикс)? Я нет. Я вообще мало знаю крупных проектов, а уж на базе какой-нибудь «Буми», тем более.
Проект можно сделать плохо, можно хорошо, а демо-сайт это "0" точка, которую можно повторить. Она может быть не идеальной, а может быть наоборот оптимизированной. Это не суть важно. Важно получить точку отсчета, с которой потом уже что-то сравнивать.
- eldorado.ru: 150-200к хитов
- compulenta.ru: 45-55к хитов
- promt.ru: 9-10к хостов
- aif.ru: 130-170к хостов
- banki.ru: 160-180к хостов
- nasta.ru: 3-4к хостов
- cosmo.ru: 400-450к хостов
Кто-то из них живет на одном сервере, кто-то на двух.
Данные из открытых источников - top.mail.ru и top100.rambler.ru
Если хотите получить среднее в час - операция деления. А вот пиковые... к сожалению у меня таких данных нет. Если поделитесь - буду благодарен.
Если настроить БУС для быстрой работы потребовалось "4 месяца высококвалифицированных специалистов", то не вижу пользы от полученных данных теста и от использования БУС вообще. Какой смысл пользоваться коробкой, если ее надо 4 месяца настраивать, чтоб она начала работать с приемлимой скоростью?
У меня еще вопросы, т.к. у вас не совсем четко описано.
По серверам. Для MySQL использовался отдельный сервер?
По результатам.
Я не понял, как из этих чисел получается "Обработано запросов 1593983", потому что:
"Продолжительность теста 84320 сек" / "Время построения страницы, сек. 0,22" = ~ 383272,(72)
есть только 2 варианта:
1. вы посчитали картинки, css и прочую статику за "запрос"
2. либо вы каждую страницу с 3го раза нормально получаете
Мне не известно. Назовете?
А вы посмотрите раздел внимательнее, там доступны для скачивания все результаты (и конфиги). Пользуйтесь. А время мы тратили, чтобы изучать, измерять, строить графики, делиться с разработчиками промежуточными результатами и вносить правки в продукт и т.д.
Нет. Все на одной машине
есть только 2 варианта:
1. вы посчитали картинки, css и прочую статику за "запрос"
2. либо вы каждую страницу с 3го раза нормально получаете
Есть еще и 3-ий вариант - Паралельные потоки. Вы в стремлении "найти побольше недостатков", немного забылись.
Вообще, это детское бахвальство и задирание носа выглядит достаточно глупо и несерьезно, оно портит вам имидж взрослых людей. Зря вы так
Нет у меня этого стремления, не бойтесь. Я хочу объективную картину видеть, а вы пока только бахвалитесь.
Я так и не понял методику тестирования. Вы не могли бы пояснить про параллельные потоки подробнее? Я впервые слышу о таком методе, хотя мой опыт в тестировании минимален. В сети тоже ничего не нашел про это. Или ссылочку дайте где почитать, пожалуйста.
А время мы тратили, чтобы изучать, измерять, строить графики, делиться с разработчиками промежуточными результатами и вносить правки в продукт и т.д.
Если вы вносили правки в продукт в процессе тестирования - это значит, что для тестирования использовалась особая (подправленная) версия продукта, а не та, что в продаже?
Михаил, вы мне так и не ответили про "Паралельные потоки". Объясните пожалуйста, что это такое.
Приезжайте к нам в гости, я Вам с удовольствием все расскажу и покажу.
К Вам в гости я не поеду, потому как в другом городе живу.
Если Вы так не хотите объяснить, что есть "Параллельные потоки", мои подозрения о происхождении цифр теста просто подтвердятся. Пока Вы уже неделю всячески увиливаете от ответа на этот простой вопрос.
Егор, а у нас и нет задачи сравниваться с другими продуктами. Мы свой продукт развиваем и делаем лучшим.
А другие пусть повторяют потом наши шаги
Согласен с Михаилом, что бессмысленно тестировать shared-хостинге.
Почему? Почитайте описание этого хостинга и вам все станет понятно:
А другие пусть повторяют потом наши шаги Кстати, очень часто так и бывает.
Сергей, Вы правы, во многом вы первые и вас повторяют все другие местные CMS в той или иной степени. Только, заметьте, что ваши действия тоже не уникальны, вы сами повторяете за компаниями на других рынках. Те же тесты делают все, кому ни лень.
И еще для вас есть риск, что те кто за вами повторяет, будут повторять ваши шаги лучше, чем это делали вы. Потому что будут учиться на ваших ошибках и не повторять их. Так что нечему особенно радоваться. Я думаю, что это тестирование - явная ваша ошибка.
Напоследок возьмем хотя бы то, что руководитель Битрикс сидит и общается здесь с нами. Не проще ли ему это было бы отдать кому-то другому? Проще, но тут вопрос отношения к своим клиентам и партнерам.
Все это имхо.
А в чем правы, я не сообразил. У меня, конечно, мало времени перечитывать все, но я никакой особенной точки зрения не прочитал. Извините, конечно.
И правда, на это времени мало, но это очень полезный опыт и знания.
Ну а если вы читаете и есть о чем поспорить... то значит я не зря это пишу.
Кстати, уже одна идея на подходе
До этого исторического момента в русском языке не использовалось слово "многосайтовость".
Или вообще многосайтовости в CMS не было?
Я, кстати, все жду пояснения от Токовинина про "Паралельные потоки" (авторская орфография сохранена), которая использовалась в тесте и объясняет полученные результаты.
Может, Вы, Сергей, ответите за него?
Ну вообще, не в тему поста спор тут пошел. И не думаю, что есть смысл тратить время на доказывание что и как у кого обстоит.
Мы всегда работали сами, думали своей головой и делали то, что нужно клиентам, партнерам и нам.
А это всегда пожалуйста, пусть повторяют. Идти в колее всегда легче, а прокладывать курс тяжело.
И всегда кто сзади идет, получается чище и красивее, а первому достается все негативно
Но мы уже выбрали для себя этот путь и считаем его правильным, останавливаться не собираемся.
Кстати, этими словами вы только подтверждаете мне, что идем мы правильно
В подробном отчете указано что использовался "Демо-сайт, входящий в дистрибутив продукта." () и ни какие его доработки под это тестирование не упоминаются. Однако в подписанном Вами протоколе тестирования () упоминается о том что "в целях оптимизации были отключены: "панель вывода статистики", "фото дня" на главной странице", кроме того в отчете упоминаются изменения модуля статистики. О влиянии любых незакэшированных данных на производительность говорить, думаю, не стоит.
Досадное упущение в описании, не правда ли?
Да и это просто не этично. Завтра к любому Вашему партнеру придет партнер и скажет что, мол, сделайте мне сайт на 1.5М хитов на один сервер. Битрикс, мол, сделал. И получится некрасиво. Напиример потому что по словам того же Михаила в Вашем же форуме, 1.5М при неравномерной нагрузке превращается в 650к.
В общем Вы меня не убедили.
В подробном отчете указано что использовался "Демо-сайт, входящий в дистрибутив продукта." () и ни какие его доработки под это тестирование не упоминаются. Однако в подписанном Вами протоколе тестирования () упоминается о том что "в целях оптимизации были отключены: "панель вывода статистики", "фото дня" на главной странице", кроме того в отчете упоминаются изменения модуля статистики. О влиянии любых незакэшированных данных на производительность говорить, думаю, не стоит.
Досадное упущение в описании, не правда ли?
Проще всего взять и попробовать самому.
На днях мы подписывали крупный договор. У клиента сотни сайтов на Стандарте должны быть на одной машине.
Ему нужно было в течение дня продемонстрировать, что машина обработает 6 миллионов хитов в равномерной нагрузке.
Взяли обычный дистрибутив Стандарта, (я взял, если быть точным. Есть у меня такое хобби, заниматься нагруженными проектами
Не верите, ну сделайте сами. Зачем столько сомнений, опасений, что вас обманывают.
Все это делалось не только для пиара и клиентов, все это делалось и для партнеров.
Да, Битрикс при желании можно разогнать до достаточно неплохих показателей. Тот же evraz.com на одном сервере совершенно вальяжно держал 75`000 хитов в день. Но как показывает практика, обеспечение производительности на реальных проектах на Битриксе, зачастую, становится слишком дорогой штукой.
К прмеру, чтобы тот же evraz.com нормально бегал пришлось потратить не один день на укрощение Битрикса. Именно на укрощение. Вот не умеет Битрикс выбирать связанные сущности, хоть тресни. Соответственно когда нужно реализовывать сложные связи - или добавлять сервера в неограниченном количестве или извращаться поперек течения.
Да, я иронично отношусь к данному тесту. Заставьте тестового пользователя писать что-то в форум, авторизовываться на сайте, покажите ему динамические баннеры - приблизьте тестирование к боевым условиям и производительность снизится на порядок. Товарищи из QSoft провели на самом деле большую работу, я не умаляю их заслугу и уж ни в коем мере не обвиняю в непрофессионализме. Но они подогнали стенд под идеально ровную посещаемость и идеально неменяемый контент, а это совсем не то же самое что боевой сайт.
Вот чего действительно хотелось бы в плане производительности - так это действенных и отлаженных инструментов для организации сложной бизнес-логики. У Вас сейчас основной упор делается на кэш, но не все и не всегда закэшируешь. Вот если бы изменения коснулись работы продукта мимо кэша - да, это было бы действительно здорово и полезно. Даже я ворчать на производительность перестал бы
Тогда это был бы уже не Битрикс, а другой продукт
Битрикс сегодня при своем функционале и возможностях, я уверен, один из наиболее производительных продуктов! Вы пробовали хоть раз запустить под нагрузку продукт MS, Oracle или IBM для сайта или для Интранета? Да даже бесплатные системы которые так часто упоминаются? Ну серьезно. Я некоторым опытом располагаю. Но я ни разу не видел нагрузочных тестов. Честно скажу и не искал, но если есть, пришлите мне в почту, будет любопытно.
У нас есть несколько клиентов, которые перешли со своих старых платформ на нашу и уменьшили число серверов в несколько раз. У одного клиента было 6 серверов, осталось два.
Да, проекты для большой нагрузки требуют внимательной разработки, голову никто не отменял, понимание особенностей больших проектов тоже надо понимать. Но сегодня планку Большого проекта мы подняли очень высоко, а уровень знаний для создания такого проекта значительно снизили.
Ладно, чего мы тут спорим. Работать нужно, а не перетряхивать свои сомнения.
Ну не все так плохо, как кажется.
Да нет, Даниил, не упадет производительность так жутко, как вы говорите. Да, конечно может измениться и измениться на рабочем проекте. Я знаю сайт на котором каталог товаров обновляется практически постоянно и еще связь с ERP реализована с постоянными операциями за запись данных. Ну сделали бы мы тест такой системы, кому-то это дало бы информацию? Мы тестировали типовую публичку в первую очередь, чтобы получить информацию о производительности ядра и продукта, о результатах наших усилий по оптимизации, а не о качестве сборки сайта. Но повторяться не буду, уже столько раз об этом говорили...
Вы не правы, упор сегодня не только в кеширование делается. Посмотрите раздел.
Заниматься вопросом производительности мы начали именно с ядра продукта, с оптимизации кода, исключения числа запросов, оптимизации запросов... потом сделали несколько видов кэширования и развили имеющиеся. И только потом сделали Автокеширование как составную часть вторых компонент. Да, сделано это, чтобы облегчить жизнь разработчикам при работе над большими проектами и при работе на виртуальном хостинге. Очень это помогает одним махом перевести сайт в автоматический режим кэширования.
А чего стоят инструменты отладки! Сегодня проанализировать проект можно за 10-30 минут, найти проблемный компонент и устранить проблему. И это уже как раз для сложных проектов.
Есть реклама и статистика, в большинстве проектов. Эти данные не кэшируются, как например, в тестируемом Бизнесе.
На странице данные обновляются по-разному. Например лента новостей может обновляться только когда появится новая запись, а счетчик материалов просто раз в час, т.е. зависит от бизнес-приложения.
Хотя конечно было бы очень просто кешировать готовую страницу в HTML.
Но статика - это уже очень неудобно, не соответствует бизнес задачам клиентом.
Потому и тестируем работающую бизнес-логику.
Но почему вы не делаете кеширование в статику для случая, когда нет статистики?
На счет "данные обновляются по-разному" это я что-то не пойму.
80% сайтов обновляются не чаще раза в день. Что мешает записать всю страницу целиком в HTML-файл, после того как поменялась одна новость?
И потом целый день отдавать этот файл всем посетителям со скоростью апача или nginx?
А так без проблем, хоть готовый HTML кэшировать, хоть выставьте заголовок и время истечения поставьте и сложите копию в кэш front-end.
80% сайтов обновляются не чаще раза в день. Что мешает записать всю страницу целиком в HTML-файл, после того как поменялась одна новость?
И потом целый день отдавать этот файл всем посетителям со скоростью апача или nginx?
Это исключение из правила. Обычный проект обновляется неравномерно.
Часть страницы по своему графику, часть по другому.
Есть проект позволяет кэшировать страницу в чистый HTML - пожалуйста, вы можете так сделать.
Просто мы не считаем это удобным для владельца ресурса и для посетителей даже на статических страницах.
Я уже не говорю о проектах, где число статических страниц может быть очень большим и зависеть от посещаемости, запросов пользователей, фильтров и т.п. вещей.
на счёт кэширования имею замечание: на форуме уже высказывалось предложение реализовать некую систему событий, мол, "элемент такой-то изменён - удалить из кеша и закешировать снова". на данный момент такой проверки нет, что негативно сказывается и на скорости (часто вместе с устаревшим кешем приходится обновлять и валидный).
По моим данным, работает модуль очень хорошо даже не смотря на появление равномерного показа рекламы по контрактам рекламодателей.
Этот вопрос неоднократно обсуждали. Но цена реализации получается очень большой в целом на проект.
Более выгодно получается делать управляемое кешированием в тех компонентах, где это нужно. Кстати, во многих наших компонентах сделано управляемое кеширование. Так, например, блог скидывает сам кеш, когда добавлено новое сообщение.