Comments 68
Отдаю предпочтение оттестированной, стабильной версии с поддержкой вендора и большим комьюнити.
Я даже не знаю что сказать… просто… просто это один из самых бессмысленных бенчмарков за последнее время… Ни нормальной методики тестирования (измерение RPS через какой ab), ни мониторинга потребления ресурсов нормального… не понятно так же что вы тестили, настройки MySQL дефолтные ставили?
Короче… печально все это…
И да, где вариант «предпочитаю не использовать продукты от no-name вендоров» или «не использую CMS в принципе»
Короче… печально все это…
И да, где вариант «предпочитаю не использовать продукты от no-name вендоров» или «не использую CMS в принципе»
не понятно так же что вы тестили
То есть изложения в первых 2х пунктах для вас не ясны?
Да. Мне не ясно что скрывается за «Wordpress». Просто чистая установка? Какой смысл считать «чистую установку»? В разных CMS из коробки идет разный функционал. Следовательно нужно потратить время, подбить каждую CMS под одинаковый функционал и только потом производить замеры. Зачем вы учитываете размер дистрибьютива и количество файлов? При наличии APC/OpCache (а оно есть на любом хостинге, если оного нету — нужно менять хостера) разницы нету вообще.
Собственно мне оценка времени выполнения запроса (обертка из microtime в index.php) уже говорит о вашем не профессионализме.
Собственно мне оценка времени выполнения запроса (обертка из microtime в index.php) уже говорит о вашем не профессионализме.
Просто чистая установка?
Да, чистая установка дистрибутива, предоставляемого вендором. Действительно, я не занимался «тюнингом» каждой системы до максимально производительного уровня, да и если бы занимался — все равно нашлись бы те, кому тест показался бы не объективным.
Какой смысл считать «чистую установку»
А какой смысл предоставлять «чистую установку»?
Ну вы юморист. Рассмешили меня до колик. В ваших тестах самая быстрая CMS та, в которой меньше всего загружается и в которой меньше всего функциональности.
Вот поэтому ваши тесты — гавно, а Fesor — абсолютно прав
Вот поэтому ваши тесты — гавно, а Fesor — абсолютно прав
А скорость работы сайта состоящего из index.html не тестировалась?
Да, по мере роста количества материалов на сайте ситуация может существенно измениться, но резульат такого теста будет говорить о многом.
В CMS важно не то как быстро она делает SELECT count(*) FROM posts и убеждается что постов ноль, а то как она себя ведет под реальной нагрузкой.
Мне бы, например, было бы нтересно посмотреть на эволюцию времени отклика в зависимости от количества записей при обращении к случайным страницам. Увидеть «полочки», понять почему они происходят и как на «полочке» продержаться подольше.
Да, по мере роста количества материалов на сайте ситуация может существенно измениться, но резульат такого теста будет говорить о многом.
В CMS важно не то как быстро она делает SELECT count(*) FROM posts и убеждается что постов ноль, а то как она себя ведет под реальной нагрузкой.
Мне бы, например, было бы нтересно посмотреть на эволюцию времени отклика в зависимости от количества записей при обращении к случайным страницам. Увидеть «полочки», понять почему они происходят и как на «полочке» продержаться подольше.
Вот это я понимаю, уже интересно читать, конечно есть ошибки, в комментариях они написаны, но статья сделанная Вами уже имеет ценность и может повлиять на выбор CMS в Вашу пользу.
повлиять на выбор CMS в Вашу пользу.
и
$_test_loadstart = microtime(true);
// код CMS
$_test_loadend = microtime(true);
$_test_loadtime = number_format($_test_loadend - $_test_loadstart, 3);
$_test_memory = number_format(memory_get_usage()/1048576, 3);
@file_put_contents($_SERVER['HTTP_HOST'] . '.txt', $_test_loadtime . ';' . $_test_memory . "\n", FILE_APPEND);
вот вообще не согласуются. Вы помниться в одном из топиков возмущались изза рекламы, бессмысленной рекламы и т.д.
Вместо тысячи слов о хреновом качестве продукта, оставлю ссылочку на гитхаб, чтобы до вас дошло насколько хрень вы только что написали
github.com/zenn1989/ffcms
github.com/zenn1989/ffcms
UFO just landed and posted this here
Вы не поверите, но с opcache результат будет пропорциональным для всех систем. Вы ведь можете провести тестирование и проверить это.
Нет не будут. Проверьте в своих же тестах, вам же просто один модуль поставить нужно и повторить. Либо выложите box для vagrant с вашим тестовым стэндом, подготовьте под каждую CMS инстанс и дайте другим погонять.
Хорошо, сейчас проверим с opcache.
UFO just landed and posted this here
Уже практически завершил тот же bench для php 5.5 + opcache / mysql 5.5, вскоре обновлю материал. По визуальной оценке — да, opcache как и планировалось выполнил свою функцию — кол-во потребляемой памяти существенно снизилось, но время выполнения — не очень (существенные изменения в корреляции с другими заметны только у drupal).
UPD: добавил результаты бэнча с PHP 5.5 и OPCache в пост — как и говорил, результаты пропорциональны.
Нет пункта в опросе «Предпочитаю продукты с хорошо документированным расширяемым кодом».
Все эти пузомерки не имеют никакого смысла, поскольку в продакшене обычно ставится что-то вроде «w3c total cache» и работа CMS сводится в большинстве сценариев к отдаче статичного контента.
Все эти пузомерки не имеют никакого смысла, поскольку в продакшене обычно ставится что-то вроде «w3c total cache» и работа CMS сводится в большинстве сценариев к отдаче статичного контента.
MODX-а не хватает для полного счастья. Чтобы уж видно было насколько «крут» этот движок в контексте данного тестирования.
Не смотря на странность теста я не поленился вызвать у себя вот такой сниппет:
Результат — 0.020;4.299, то есть 0.02 секунды генерится страница и потребляет 4.3мегабайта ОЗУ. Не знаю, в чем смысл тестировать пустой дистрибутив — но вот такие цифры у меня в виртуальной машине.
На хостинге, на реальном рабочем сайте с 3000 документов выходит 0.046 сек. и 4.677 мб.
Понятно, что вызов сниппета в контенте страницы может не отражать истинного положения вещей — поэтому я добавил еще тег [^t^], который MODX выставляет в почти самом конце работы. Он показал 0.0203 s и 0.0496 s соотвественно.
На виртуалке MODX 2.3.1, на хостинге 2.2.15.
<?php
$_test_loadend = microtime(true);
$_test_loadtime = number_format($_test_loadend - $modx->startTime, 3);
$_test_memory = number_format(memory_get_usage()/1048576, 3);
return $_test_loadtime . ';' . $_test_memory . "\n";
Результат — 0.020;4.299, то есть 0.02 секунды генерится страница и потребляет 4.3мегабайта ОЗУ. Не знаю, в чем смысл тестировать пустой дистрибутив — но вот такие цифры у меня в виртуальной машине.
На хостинге, на реальном рабочем сайте с 3000 документов выходит 0.046 сек. и 4.677 мб.
Понятно, что вызов сниппета в контенте страницы может не отражать истинного положения вещей — поэтому я добавил еще тег [^t^], который MODX выставляет в почти самом конце работы. Он показал 0.0203 s и 0.0496 s соотвественно.
На виртуалке MODX 2.3.1, на хостинге 2.2.15.
Я понимаю, что предложенный ТС тест можно при желании провести и на своем сервере. Но так или иначе, результаты будут отличаться из-за: объема оперативной памяти, процессора, скорости доступа к харду и т.д. и т.п.
Если очень нужно, то можно, конечно, прогнать тесты всех предложенных CMS, чтобы понять как это смотрится на общем фоне. Но зачем? На реальных сайтах данный тест может вывести любого аутсайдера на первое место.
Если очень нужно, то можно, конечно, прогнать тесты всех предложенных CMS, чтобы понять как это смотрится на общем фоне. Но зачем? На реальных сайтах данный тест может вывести любого аутсайдера на первое место.
Согласен, тест вообще ни о чем.
Но не думаю, что в окружении автора 0.0496 s и 4.3 mb увеличатся в разы. Так что, можно сделать вывод, что MODX неплохо смотрится среди остальных.
Честно говоря, я вообще не верю, что Umi.CMS загружается 3 секунды из коробки, Drupal 0.2 сек., а Wordpress — 0.5. Наверное, там сразу выводится шаблон со всякими меню, хлебными крошками и прочим.
Если так — то тест становится еще более странным и бесполезным.
Но не думаю, что в окружении автора 0.0496 s и 4.3 mb увеличатся в разы. Так что, можно сделать вывод, что MODX неплохо смотрится среди остальных.
Честно говоря, я вообще не верю, что Umi.CMS загружается 3 секунды из коробки, Drupal 0.2 сек., а Wordpress — 0.5. Наверное, там сразу выводится шаблон со всякими меню, хлебными крошками и прочим.
Если так — то тест становится еще более странным и бесполезным.
Можно оформить докер контейнеры под каждую CMS-ку, выложить в опенсурс что бы люди могли посмотреть на конфигурацию и нутро. А потом просто на том же диджитал оушине прогнать все контейнеры. Можно подготовить скажем отдельно контейнер с базами данных (причем было бы прикольно прогнать на mysql и postgresql если кто поддерживает), сделать отдельно базу данных с небольшим набором данных, средним и большим (просто нагенерить фэйкером каким).
Но это долго, сложно и непонятно зачем. Если люди парятся изза производительности они либо сами потратят время на оптимизацию/настройку кешеров либо пригласят специалиста. И уж точно не будут разворачивать это добро на шаред хостингах.
Но это долго, сложно и непонятно зачем. Если люди парятся изза производительности они либо сами потратят время на оптимизацию/настройку кешеров либо пригласят специалиста. И уж точно не будут разворачивать это добро на шаред хостингах.
Собака напугала. Если у вас не пишется в файл, то надо поправить. Если пишется, то зачем собака? По привычке поставили? Это вот предположение и пугает.
И что меряется я тоже не понял. Но ты не прекращай. Замути ещё разик с учётом тонких моментов.
И что меряется я тоже не понял. Но ты не прекращай. Замути ещё разик с учётом тонких моментов.
Извините, но так будете общаться со своими друзьями — вроде бы образованные люди здесь находятся, или нет?
Похоже, что автор молча убрал собаку из своего кода, попутно нахамив и не забыв повыкать для проформу. Изначально логгер времени выглядел так:
@file_put_contents($_SERVER['HTTP_HOST']. '.txt', $_test_loadtime. ';'. $_test_memory. "\n", FILE_APPEND);
@file_put_contents($_SERVER['HTTP_HOST']. '.txt', $_test_loadtime. ';'. $_test_memory. "\n", FILE_APPEND);
вы меня простите, но как насчёт файл локов на дозапись ваших логов? Это смотрится не очень профессионально что-ли.
Вы действительно считаете что 1 запись существенно повлияет на результаты тестирования целого продукта? Что вы имели в виду, говоря о «файл локах» — подразумевалась блокировка файла на время записи (LOCK_EX) или что-то иное?
Вы действительно думаете что в ваших бенчмарках есть смысл? С архитектурной точки зрения все одно и тоже. Ничего принципиально новго вы не предлагаете. А так если реально вопрос производительности напрягает, всегда можно впилить кеш или вооб
А файл локи да, не нужны. Точно так же как и не нужны бенчмарки без конкурентных запросов.
А файл локи да, не нужны. Точно так же как и не нужны бенчмарки без конкурентных запросов.
А вы действительно считаете, что вашей прямой обязанностью является нагадить в каждой ветке комментариев очередным сообщением о том, что по вашему мнению, которое по всей видимости вы ставите выше остальных, данные тесты бессмысленны?
И да, я сделал аналогичный тест с php 5.5 и opcache и вы не поверите — результаты, как я ранее вам говорил — пропорциональны тем, что были получены ранее.
Тест с OPcache и php 5.5: docs.google.com/spreadsheets/d/1WS5hJkzAbTSkAndf-P1PXemgAbY-J1W1m3G1agpU6ks/edit?usp=sharing
И да, я сделал аналогичный тест с php 5.5 и opcache и вы не поверите — результаты, как я ранее вам говорил — пропорциональны тем, что были получены ранее.
Тест с OPcache и php 5.5: docs.google.com/spreadsheets/d/1WS5hJkzAbTSkAndf-P1PXemgAbY-J1W1m3G1agpU6ks/edit?usp=sharing
Ну как не удивительно, да. Это скорее теоретический тест у вас. Не учтена статика, ajax и куча мелочей из коробки.
Это как-то непрофессионально, писать о своём продукте на хабре только хорошее, причём основывать все на таком скудном тесте.
Рекомендую для начала вам посмотреть как другие на хабре тестируют и пишут.
Рекомендую для начала вам посмотреть как другие на хабре тестируют и пишут.
Жумла лучше друпала? Серьёзно?
Вот у меня сейчас тюненый нжикнкс, мускуль, пхпфпм с opcache с хитом 100%. + к этому CDN. И по сравнению с какой CMS мне теститься? По каким критериям?
Не знаю, что вы там делали с вордпрессом, но мой бложек на WP с кастомным шаблоном (который под скорость не оптимизировали никогда) и кучей плагинов грузится в 3-4 раза быстрее, чем exampl-ы джумлы и вордпресса пустые с того же сервера.
А wp-сайт на bootstrap-шаблоне выигрывает у моего блога ещё 200 мс.
А wp-сайт на bootstrap-шаблоне выигрывает у моего блога ещё 200 мс.
Рандомные цифры вы какие-то говорите… причем тут bootstrap вообще…
Bootstrap здесь при этом — vlad.pro/
А цифры не рандомные.
А цифры не рандомные.
И какой смысл такого теста, вы бы набросали в базу каждой CMS к примеру несколько десятков тысяч постов, комментов и т.п. А так получилось, что CMS у которой меньше функционала, та и победила. Да и обычно самые веселые косяки производительности вылазят когда, уже база содержит большое количество контента.
Спасибо.
Провел тестирование и своей CMS, сделал обобщающие графики.
Несмотря на наличие расширенного функционала моя CMS оказалась быстрее описанной из-за особенностей архитектуры и голого PHP.
Несмотря на скорость (и это без кеширования), это не делает её лучшей.
Провел тестирование и своей CMS, сделал обобщающие графики.
Несмотря на наличие расширенного функционала моя CMS оказалась быстрее описанной из-за особенностей архитектуры и голого PHP.
Несмотря на скорость (и это без кеширования), это не делает её лучшей.
вот эту копипасту
неплохо было бы сократить, используя позднее статическое связывание
public static function getInstance() {
if(is_null(self::$instance)) {
self::$instance = new self();
}
return self::$instance;
}
неплохо было бы сократить, используя позднее статическое связывание
Да, я уже над этим задумался. Но решение есть несколько иное — т.к. все одиночки наследуют \engine\singleton — внедрить в него тот самый статический getInstance() и записывать в локальную статическую переменную внутри singleton ссылку на инициированный класс. Возможно, ваше решение лучше(если есть что «почитать» или пример — пришлите в л.с.). Спасибо.
Ну например:
abstract class singleton {
public static function getInstance() {
static $instance = null;
if(is_null($instance)) {
$instance = new static();
}
return $instance;
}
protected final function __construct() {}
protected final function __clone() {}
protected final function __wakeup() {}
}
Мой вариант был чутку иным:
но ваш действительно проще и извращаться с phpdoc не нужно, да и вызов instance так же происходит лишь 1 раз.
abstract class singleton {
protected static $instance = array();
protected final function __construct() {}
protected final function __clone() {}
protected final function __wakeup() {}
public static function getInstance() {
$call_target = get_called_class();
if(!array_key_exists($call_target, self::$instance))
self::$instance[$call_target] = new $call_target;
return self::$instance[$call_target];
}
но ваш действительно проще и извращаться с phpdoc не нужно, да и вызов instance так же происходит лишь 1 раз.
Может я совсем туп, но я не понял…
Можете пояснить как это должно работать?
Можете пояснить как это должно работать?
А что тут пояснять то? Запрещаем инстанцирование из вне класса (не только new но и десериализацию и т.д.) путем добавления модификатора доступа protected. Так же инстанс класса будет лежать в статической переменной $instance которая так же не доступна из вне. Если переменная пустая — надо создать инстанс класса. Тут на помощь приходит позднее статическое связывание — static указывает на класс, из под которого мы обращались к статическому методу. Вызываем конструктор (потому что изнутри можно) и возвращаем инстанс.
Как раз это понятно — классическая реализация синглтона на PHP.
Зачем static $instance = null; и чем это лучше варианта с self::?
Зачем static $instance = null; и чем это лучше варианта с self::?
Потому что можно. Зачем захламлять базовый класс лишними приватными статическими свойствами? Реализация выходит чище и более универсальной. Можно потом в трейт запихнуть и вообще отказаться от излишнего наследования.
Это лучше так же тем, что для автокомплита в IDE будет достаточно следующего phpdoc: @ return static, а в случае описанным мной выше придется достаточно упорно поизвращаться.
Suntechnic не про тот static. Ему любопытно почему локальной статической переменной а не приватным статическим свойством.
Дык Singleton давно уж не в почете, лет как 5.
DI, IoC и все такое. Возможно стоит вовсе пересмотреть отношение к этому паттерну.
DI, IoC и все такое. Возможно стоит вовсе пересмотреть отношение к этому паттерну.
Мне чем то напомнил ваш тест вот это vanilla js
По крайней мере в таком же стиле все описано.
А если серьезно многие CMS медленно работают в единичном запросе, но зато выигрывают при реальном использовании сайта, когда запросов 100 и 1000 в миниту или даже секунду. Начинает работать кеширование, некоторые данные хранятся в оперативной памяти и тем самым доступ к ним можно получить намного быстрее чем из базы данных.
Вместо того чтобы мерить один скрипт вы бы посчитали бы количество запросов к базе, нагрузку на базу если разом сделать 1000 запросов одной страницы. Если разом запросить 1000 разных страниц, под разными пользователями. Вот тогда и смотрите что будет быстрее работать.
А эти исследования чушь, бессмыслица полная.
По крайней мере в таком же стиле все описано.
А если серьезно многие CMS медленно работают в единичном запросе, но зато выигрывают при реальном использовании сайта, когда запросов 100 и 1000 в миниту или даже секунду. Начинает работать кеширование, некоторые данные хранятся в оперативной памяти и тем самым доступ к ним можно получить намного быстрее чем из базы данных.
Вместо того чтобы мерить один скрипт вы бы посчитали бы количество запросов к базе, нагрузку на базу если разом сделать 1000 запросов одной страницы. Если разом запросить 1000 разных страниц, под разными пользователями. Вот тогда и смотрите что будет быстрее работать.
А эти исследования чушь, бессмыслица полная.
С UMI в целом все более-менее прогнозируемо, там сферическое ООП на ООП сидит в вакууме и ООП погоняет.
Сравнение через выполнение index.php не слишком корректно — у разных CMS в демо-сайтах разное количество модулей прогружается.
Т.е. тот же битрикс интересно было бы потестировать хотя бы на инфоблоках с большим количеством вложенных категорий с кучей доп. параметров и счетчиком элементов в категории.
Т.е. сравнивать на конкретных примерах — интернет-магазин, новостной сайт и т.д. и т.п.
Сравнение через выполнение index.php не слишком корректно — у разных CMS в демо-сайтах разное количество модулей прогружается.
Т.е. тот же битрикс интересно было бы потестировать хотя бы на инфоблоках с большим количеством вложенных категорий с кучей доп. параметров и счетчиком элементов в категории.
Т.е. сравнивать на конкретных примерах — интернет-магазин, новостной сайт и т.д. и т.п.
Да, соглашусь у многих после «стандартной установки» сайт уже набит материалами и кучей модулей(bitrix, umi) — об аутентичности для всех систем я не заявлял. И да, все выбранные cms обладали более-менее схожим функционалом (интернет магазинов не было в тестировании).
Но довести все 10 систем до «одинаково равного уровня наполнения» — очень затратно и опять же вызовет столько же вопросов о том, действительно ли все системы находились в равных условиях.
Как говориться — не важно как тестируют, важно как считают :)
Но довести все 10 систем до «одинаково равного уровня наполнения» — очень затратно и опять же вызовет столько же вопросов о том, действительно ли все системы находились в равных условиях.
Как говориться — не важно как тестируют, важно как считают :)
Оу…
Я тут пилю вот прямо сейчас решение для одной CMS заменяющее кое-какой стандартный функционал. И ломаю голову над тем, как же объективно сравнить производительность моего решения со штатным в рамках одной CMS.
Банальный пример — при выводе списка новостей, может понадобиться только заголовок новости, а может понадобиться и кусок текст в качестве стрейпа. Штатное решение всегда извлекает текст, а мое только по необходимости. (искусственный пример — по факту всё сложнее, но смысл тот же)
В каком режиме сравнивать? Если с извлечением и обработкой текста производительность похожая, а если нет — я рву штатное в клочья. Понятно, что нужно тестить оба случая, но в каком процентном соотношении смешать результат? А ведь таких вопросов даже при выводе просто списка новостей, у меня уже под дюжину.
А тут вононо как оказывается надо. Автор, ты бог бенчмаркостроения.
Я тут пилю вот прямо сейчас решение для одной CMS заменяющее кое-какой стандартный функционал. И ломаю голову над тем, как же объективно сравнить производительность моего решения со штатным в рамках одной CMS.
Банальный пример — при выводе списка новостей, может понадобиться только заголовок новости, а может понадобиться и кусок текст в качестве стрейпа. Штатное решение всегда извлекает текст, а мое только по необходимости. (искусственный пример — по факту всё сложнее, но смысл тот же)
В каком режиме сравнивать? Если с извлечением и обработкой текста производительность похожая, а если нет — я рву штатное в клочья. Понятно, что нужно тестить оба случая, но в каком процентном соотношении смешать результат? А ведь таких вопросов даже при выводе просто списка новостей, у меня уже под дюжину.
А тут вононо как оказывается надо. Автор, ты бог бенчмаркостроения.
Мауриц Эшер позавидовал бы автору этой картинки
Sign up to leave a comment.
Тестирование производительности популярных (и не очень) CMS