Тестирование производительности популярных (и не очень) CMS

    php script load total time seconds


    Приветствую тебя, хабражитель! Разрабатывая FFCMS для своих проектов одной из основных своих целей я выделял быструю скорость работы и минимальное потребление ресурсов оборудования — однако все значения можно оценить лишь в сравнении, что я и постараюсь сделать в данной статье.

    В прошлой моей публикации некоторые пользователи поинтересовались вопросом производительности системы и я решил провести тестирование различных популярных и молодых CMS по состоянию на 18 октября 2014 года. Хочется отметить — тестирование системы проводилось сразу же после ее установки и данные могут существенно измениться в ту или иную сторону в зависимости от периода использования системы — увеличения базы данных, количества файлов и прочие условия.

    Предисловие


    Перед проведением подобного тестирования я хотел посмотреть на результаты аналогичных тестов — ведь вероятней всего их уже проводили и до меня. Однако к моему разочарованию, мне не удалось найти ни единого развернутого тестирования, в котором бы сравнивались хотя-бы 3 или более систем по многим критериям (возможно я плохо искал?). Это удивительно, ведь популярными CMS пользуются десятки (а то и сотни) тысяч веб-мастеров, программистов и крупных компаний — неужели вопрос потребляемых ресурсов системой не интересует вовсе никого?

    Объекты тестирования


    Для тестирования я выбрал ряд популярных на данный момент систем, как коммерческих так и бесплатных. Были выбраны 10 систем, ниже приведены их названия и используемые версии:
    • Bitrix standart — 14.5.0
    • WordPress 4.0
    • Drupal 7.32
    • Joomla! 3.3.6
    • Umi.cms 2.9.7
    • FFCMS 2.0.3
    • InstantCMS 2.1.1
    • KodiCMS 12.20.37(master)
    • NetCat Standart 5.4
    • HostCMS.Халява 6.1.6

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

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


    Для того, чтобы результат тестирования был однородным для всех продуктов была создана виртуальная машина, на которую был установлен веб сервер, база данных и прочее необходимое ПО для тестирования. В качестве стенда использовались:
    • Apache 2.2.27;
    • PHP 5.3.28;
    • MySQL Community Server 5.5.38-log;
    • Модули PHP: Zend Engine v2.3.0 (никаких opcache, xcache, acp, eaccelerator);
    • Apache benchmark Version 2.3.

    * UPD: так же был проведен второй тест на php 5.5 с включенным OPCache как запросили критики в комментариях — его результат пропорционален основному тесту. Результаты приведены в последнем разделе.

    Каждая CMS была установлена в виртуальной среде стенда после чего в ее код (чаще всего index.php) было добавлено несколько строк, которые позволили сохранять результат о времени выполнения скрипта и объеме затраченной памяти:

    $_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);
    

    В результате на выходе был получен файл domain.local.txt в котором содержались данные о времени загрузки скрипта и потреблении оперативной памяти.
    Для создания запросов на сайт был использован ab (Apache benchmark) без создания параллельных запросов — целью не было тестирование apache, целью было получить средние результаты для каждой CMS:

    ab -n 1000 http://domain.local/ > ~/bench/ab/domain.local.txt
    


    Методика оценки результатов


    Всего по выше описанной технологии проведения тестирования была дана оценка по следующим разделам:
    • Описательная оценка (Basic) — размер дистрибутива, кол-во файлов, размер и характеристики базы данных
    • Оценка скорости загрузки скрипта (phpload_time)
    • Оценка размера потребленной оперативной памяти (phpload_memory)
    • Оценка результатов тестирования Apache benchmark (apache_benchmark)

    В каждом разделе тестирования для каждой CMS были выставлены оценки (-2 <= x <= +2) в зависимости от полученных результатов (личных) и средних (avg) всей выборки:
    • -2 — худший результат в данном тесте
    • -1 — результат, худший чем среднее в данном тесте
    • +0,5 — результат близкий к среднему в пределах standart devination
    • +1 — результат, лучший чем среднее в данном тесте
    • +2 — лучший результат в данном тесте

    По результатам тестирования во всех категориях по всем критериям была составлена результирующая таблица, в которой указаны суммарные результаты по всем тестам.
    * Хочется так же остановиться на 1 моменте — UMI.CMS при тестировании показывала запредельные результаты по скорости загрузки, поэтому ее результаты были исключены из расчета AVG в некоторых категориях тестирования.

    Тестирование


    Раз с материалом и методикой тестирования мы ознакомились — перейдем непосредственно к самому тестированию. Ниже предоставлены итоговые результаты по каждой из категорий тестирования.

    Результаты тестирования в удобном формате: Google spreadsheet
    Результаты для PHP 5.5 с OPCache (пропорциональны основным): Google spreadsheet.

    Описательная оценка


    Test/CMS Bitrix
    Wordpress Drupal Joomla Umi.CMS FFCMS InstantCMS KodiCMS
    NetCat
    HostCMS AVG MIN MAX
    Installed size(MB) 191 18,5 11,7 20,1 105 18,9 11,9 23,4 98,4 17,5 51,64 11,7 191
    File count 29908 1175 1074 5267 7128 1682 1650 3009 6391 2919 6020,3 1074 29908
    Mysql table count 241 11 74 68 97 22 84 33 155 114 89,9 11 241
    Mysql table rows 21918 126 1421 461 14616 187 12587 46 31467 20302 10313,1 46 31467
    Mysql database size(MB) 11 0,56 4,6 3,9 6,2 0,356 6,8 0,948 2,7 1,9 3,8964 0,356 11
    SUMMARY POINTS -9 6 5 5,5 -5 6 1 6 -4 1

    Оценка скорости загрузки скрипта


    Test/CMS Bitrix
    Wordpress Drupal Joomla Umi.CMS FFCMS InstantCMS KodiCMS
    NetCat
    HostCMS AVG MIN MAX
    AVG loadtime (sec)
    0,50 0,497733 0,210623 0,325381 2,99 0,090089 0,548239 0,213725 0,3279 0,70523 0,38 0,09 0,71
    MIN loadtime (sec)
    0,45 0,467 0,19 0,305 2,9 0,083 0,518 0,194 0,304 0,144 0,30 0,08 0,52
    MAX loadtime (sec)
    0,69 0,661 0,317 0,489 3,218 0,135 0,851 1,387 2,076 0,91 0,83 0,14 2,08
    SUMMARY POINTS -1 -1 3 2,5 -6 6 -2,5 1 -4 -2


    Оценка размера потребленной оперативной памяти


    Test/CMS Bitrix
    Wordpress Drupal Joomla Umi.CMS FFCMS InstantCMS KodiCMS
    NetCat
    HostCMS AVG MIN MAX
    AVG memory (mb)
    28,944115 22,992 18,144003 12,556 23,089791 3,181 5,953808 6,485019 13,696 10,789239 14,5830975 3,181 28,944115
    MIN memory (mb) 28,942 22,992 18,144 12,556 22,784 3,181 5,951 6,485 13,696 4,213 13,8944 3,181 28,942
    MAX memory (mb)
    29,177 22,992 18,147 12,556 23,095 3,181 6,885 6,504 13,696 10,848 14,7081 3,181 29,177
    SUMMARY POINTS -6 -3 -3 3 -3 6 3 3 3 -1


    Оценка Apache benchmarks


    Test/CMS Bitrix
    Wordpress Drupal Joomla Umi.CMS FFCMS InstantCMS KodiCMS
    NetCat
    HostCMS AVG MIN MAX
    Time taken for tests (sec) 527,433 520,498 230,91 340,219 13 032,86 97,178 555,886 224,176 343,965 727,217 396,3868889 97,178 727,217
    Complete requests 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000 1000
    Failed requests 965 0 0 0 697 0 0 0 0 955 213,3333333 0 965
    Requests per second (#/sec) 1,9 1,92 4,33 2,94 0,08 10,29 1,8 4,46 2,91 1,38 3,547777778 1,38 10,29
    Time per request (ms) 527,433 520,498 230,91 340,219 13032,857 97,178 555,886 224,176 343,965 727,217 396,3868889 97,178 727,217
    Transfer rate 69,51 14,9 32,99 28,61 2,28 105,48 92,36 13,33 31,74 23,98 45,87777778 13,33 105,48
    SUMMARY POINTS -4 -2 4 2 -12 10 0 4 2 -6


    Итоговые результаты


    Test/CMS Bitrix
    Wordpress Drupal Joomla Umi.CMS FFCMS InstantCMS KodiCMS
    NetCat
    HostCMS
    Basic -9 6 5 5,5 -5 6 1 6 -4 1
    phpload_time -1 -1 3 2,5 -6 6 -2,5 1 -4 -2
    phpload_memory -6 -3 -3 3 -3 6 3 3 3 -1
    Apache benchmark -4 -2 4 2 -12 10 0 4 2 -6
    SUMMARY RESULT
    -20 0 +9 +13 -26 +28 +1,5 +14 -3 -8


    Итоги тестирования


    Теперь пришло время подбить итоги нашего тестирования и вкратце оценить полученный результат. Все наши результаты — расположены от 0 в 2 стороны: те, что получили отрицательный результат я бы не рекомендовал никому использовать вовсе, если вы дорожите вычислительными ресурсами (это лишь мое личное мнение — я прекрасно понимаю что функциональные возможности таких систем могут быть на порядок выше, чем у других).
    Одним из важных результатов тестирования стало так же то, что ни 1 открытая система не получила отрицательной оценки, а все коммерческие продукты оказались за данной чертой (+6 / -4 в пользу open source).
    Другие выводы мне бы делать не хотелось я лишь предоставлю вам итоговые графики важных тестов, выводы делайте сами (все картинки кликабельны):

    load memory avg graphload time avg graphsummary statistic graph

    Послесловие


    Я ни в коем случае не хотел никого обидеть — я лишь предоставил результаты субъективного тестирования различных CMS. Вы всегда в праве решать, имеет ли потребление ресурсов для вас большое значение, возможно большее, чем удобство разработки/управления сайтом.

    Результаты в удобном формате: Google spreadsheet
    Результаты для PHP 5.5 с OPCache (пропорциональны основным): Google spreadsheet
    Тестирование в plain-text: Забрать с Яндекс.диска

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

    Важно ли для вас потребление ресурсов в Web'e?

    FFCMS
    8,32
    Теперь FFCMS 3 с MVC, composer, AR!
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

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

      +3
      Отдаю предпочтение оттестированной, стабильной версии с поддержкой вендора и большим комьюнити.
        +14
        Я даже не знаю что сказать… просто… просто это один из самых бессмысленных бенчмарков за последнее время… Ни нормальной методики тестирования (измерение RPS через какой ab), ни мониторинга потребления ресурсов нормального… не понятно так же что вы тестили, настройки MySQL дефолтные ставили?

        Короче… печально все это…

        И да, где вариант «предпочитаю не использовать продукты от no-name вендоров» или «не использую CMS в принципе»
          –1
          не понятно так же что вы тестили

          То есть изложения в первых 2х пунктах для вас не ясны?
            +8
            Да. Мне не ясно что скрывается за «Wordpress». Просто чистая установка? Какой смысл считать «чистую установку»? В разных CMS из коробки идет разный функционал. Следовательно нужно потратить время, подбить каждую CMS под одинаковый функционал и только потом производить замеры. Зачем вы учитываете размер дистрибьютива и количество файлов? При наличии APC/OpCache (а оно есть на любом хостинге, если оного нету — нужно менять хостера) разницы нету вообще.

            Собственно мне оценка времени выполнения запроса (обертка из microtime в index.php) уже говорит о вашем не профессионализме.
              –8
              Просто чистая установка?

              Да, чистая установка дистрибутива, предоставляемого вендором. Действительно, я не занимался «тюнингом» каждой системы до максимально производительного уровня, да и если бы занимался — все равно нашлись бы те, кому тест показался бы не объективным.
              Какой смысл считать «чистую установку»

              А какой смысл предоставлять «чистую установку»?
                +5
                Ну вы юморист. Рассмешили меня до колик. В ваших тестах самая быстрая CMS та, в которой меньше всего загружается и в которой меньше всего функциональности.

                Вот поэтому ваши тесты — гавно, а Fesor — абсолютно прав
                  +3
                  А скорость работы сайта состоящего из index.html не тестировалась?
                  Да, по мере роста количества материалов на сайте ситуация может существенно измениться, но резульат такого теста будет говорить о многом.

                  В CMS важно не то как быстро она делает SELECT count(*) FROM posts и убеждается что постов ноль, а то как она себя ведет под реальной нагрузкой.

                  Мне бы, например, было бы нтересно посмотреть на эволюцию времени отклика в зависимости от количества записей при обращении к случайным страницам. Увидеть «полочки», понять почему они происходят и как на «полочке» продержаться подольше.
                    –6
                    По поводу эволюции времени отклика в зависимости от разных страниц, а так же продолжительности «жизни» сайта (наполнения его базы содержимым) — действительно был бы интересный эксперимент, но он достаточно трудоемкий.
                –4
                Вот это я понимаю, уже интересно читать, конечно есть ошибки, в комментариях они написаны, но статья сделанная Вами уже имеет ценность и может повлиять на выбор CMS в Вашу пользу.
                  +1
                  повлиять на выбор 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);
                  


                  вот вообще не согласуются. Вы помниться в одном из топиков возмущались изза рекламы, бессмысленной рекламы и т.д.
                    +2
                    Вместо тысячи слов о хреновом качестве продукта, оставлю ссылочку на гитхаб, чтобы до вас дошло насколько хрень вы только что написали
                    github.com/zenn1989/ffcms
                +8
                > Модули PHP: Zend Engine v2.3.0(никаких opcache, xcache, acp, eaccelerator)
                И какой смысл тестировать в окружении, в котором их никто никогда не будет запускать?
                Хотя дайте угадаю, чтобы FFCMS выгодно смотрелась на фоне нормальных CMS.
                  –6
                  Вы не поверите, но с opcache результат будет пропорциональным для всех систем. Вы ведь можете провести тестирование и проверить это.
                    0
                    Нет не будут. Проверьте в своих же тестах, вам же просто один модуль поставить нужно и повторить. Либо выложите box для vagrant с вашим тестовым стэндом, подготовьте под каждую CMS инстанс и дайте другим погонять.
                      –1
                      Хорошо, сейчас проверим с opcache.
                        0
                        И версию PHP обновите хотя бы до 5.5, 5.3 медленная и не поддерживается уже давно.
                          0
                          Уже практически завершил тот же bench для php 5.5 + opcache / mysql 5.5, вскоре обновлю материал. По визуальной оценке — да, opcache как и планировалось выполнил свою функцию — кол-во потребляемой памяти существенно снизилось, но время выполнения — не очень (существенные изменения в корреляции с другими заметны только у drupal).
                    –4
                    UPD: добавил результаты бэнча с PHP 5.5 и OPCache в пост — как и говорил, результаты пропорциональны.
                    +3
                    Нет пункта в опросе «Предпочитаю продукты с хорошо документированным расширяемым кодом».
                    Все эти пузомерки не имеют никакого смысла, поскольку в продакшене обычно ставится что-то вроде «w3c total cache» и работа CMS сводится в большинстве сценариев к отдаче статичного контента.
                      0
                      Не забывайте про memcache который тоже кошерен в оптимизации.
                      0
                      MODX-а не хватает для полного счастья. Чтобы уж видно было насколько «крут» этот движок в контексте данного тестирования.
                        0
                        Не смотря на странность теста я не поленился вызвать у себя вот такой сниппет:
                        <?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.
                          0
                          Я понимаю, что предложенный ТС тест можно при желании провести и на своем сервере. Но так или иначе, результаты будут отличаться из-за: объема оперативной памяти, процессора, скорости доступа к харду и т.д. и т.п.

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

                            Но не думаю, что в окружении автора 0.0496 s и 4.3 mb увеличатся в разы. Так что, можно сделать вывод, что MODX неплохо смотрится среди остальных.

                            Честно говоря, я вообще не верю, что Umi.CMS загружается 3 секунды из коробки, Drupal 0.2 сек., а Wordpress — 0.5. Наверное, там сразу выводится шаблон со всякими меню, хлебными крошками и прочим.

                            Если так — то тест становится еще более странным и бесполезным.
                              +2
                              Можно оформить докер контейнеры под каждую CMS-ку, выложить в опенсурс что бы люди могли посмотреть на конфигурацию и нутро. А потом просто на том же диджитал оушине прогнать все контейнеры. Можно подготовить скажем отдельно контейнер с базами данных (причем было бы прикольно прогнать на mysql и postgresql если кто поддерживает), сделать отдельно базу данных с небольшим набором данных, средним и большим (просто нагенерить фэйкером каким).

                              Но это долго, сложно и непонятно зачем. Если люди парятся изза производительности они либо сами потратят время на оптимизацию/настройку кешеров либо пригласят специалиста. И уж точно не будут разворачивать это добро на шаред хостингах.
                          –2
                          Собака напугала. Если у вас не пишется в файл, то надо поправить. Если пишется, то зачем собака? По привычке поставили? Это вот предположение и пугает.

                          И что меряется я тоже не понял. Но ты не прекращай. Замути ещё разик с учётом тонких моментов.
                            –10
                            Извините, но так будете общаться со своими друзьями — вроде бы образованные люди здесь находятся, или нет?
                              0
                              Там написано «не прекращай», если что. Ничего оскорбительного не вижу в своём сообщении.
                              +3
                              Похоже, что автор молча убрал собаку из своего кода, попутно нахамив и не забыв повыкать для проформу. Изначально логгер времени выглядел так:

                              @file_put_contents($_SERVER['HTTP_HOST']. '.txt', $_test_loadtime. ';'. $_test_memory. "\n", FILE_APPEND);
                              +1
                              вы меня простите, но как насчёт файл локов на дозапись ваших логов? Это смотрится не очень профессионально что-ли.
                                0
                                Вы действительно считаете что 1 запись существенно повлияет на результаты тестирования целого продукта? Что вы имели в виду, говоря о «файл локах» — подразумевалась блокировка файла на время записи (LOCK_EX) или что-то иное?
                                  +4
                                  Вы действительно думаете что в ваших бенчмарках есть смысл? С архитектурной точки зрения все одно и тоже. Ничего принципиально новго вы не предлагаете. А так если реально вопрос производительности напрягает, всегда можно впилить кеш или вооб

                                  А файл локи да, не нужны. Точно так же как и не нужны бенчмарки без конкурентных запросов.
                                    –9
                                    А вы действительно считаете, что вашей прямой обязанностью является нагадить в каждой ветке комментариев очередным сообщением о том, что по вашему мнению, которое по всей видимости вы ставите выше остальных, данные тесты бессмысленны?
                                    И да, я сделал аналогичный тест с php 5.5 и opcache и вы не поверите — результаты, как я ранее вам говорил — пропорциональны тем, что были получены ранее.
                                    Тест с OPcache и php 5.5: docs.google.com/spreadsheets/d/1WS5hJkzAbTSkAndf-P1PXemgAbY-J1W1m3G1agpU6ks/edit?usp=sharing
                                      –2
                                      За речью своей следите.

                                      Он не гадит, а критикует. Причем обосновано. А его мнение уж точно выше вашего в профессиональном плане (не забывайте, что ужасный код вашей CMS мы видели на гитхабе).
                                        +1
                                        вот это поворот!
                                    0
                                    Ну как не удивительно, да. Это скорее теоретический тест у вас. Не учтена статика, ajax и куча мелочей из коробки.
                                  +5
                                  Это как-то непрофессионально, писать о своём продукте на хабре только хорошее, причём основывать все на таком скудном тесте.

                                  Рекомендую для начала вам посмотреть как другие на хабре тестируют и пишут.
                                    +4
                                    Жумла лучше друпала? Серьёзно?
                                      –1
                                      С OPCache в данном частном случае все поменялось наоборот, друпал показал лучшее время загрузки и меньшее потребление памяти после «чистой установки».
                                      +1
                                      Вот у меня сейчас тюненый нжикнкс, мускуль, пхпфпм с opcache с хитом 100%. + к этому CDN. И по сравнению с какой CMS мне теститься? По каким критериям?
                                        –1
                                        Я думаю нужно выбирать те системы, которые вам интересны как и критерии, которые считаете важными для вашего проекта.
                                        0
                                        Не знаю, что вы там делали с вордпрессом, но мой бложек на WP с кастомным шаблоном (который под скорость не оптимизировали никогда) и кучей плагинов грузится в 3-4 раза быстрее, чем exampl-ы джумлы и вордпресса пустые с того же сервера.
                                        А wp-сайт на bootstrap-шаблоне выигрывает у моего блога ещё 200 мс.
                                          –1
                                          Рандомные цифры вы какие-то говорите… причем тут bootstrap вообще…
                                            –1
                                            Bootstrap здесь при этом — vlad.pro/
                                            А цифры не рандомные.
                                              0
                                              357ms при пинге в ~45ms и да, у вас там тупо статическая страничка по сути… какой вообще смысл отдавать ее динамически если можно закешировать.

                                              И да, bootstrap вообще не причем. Или же вы говорили о таких параметрах как время срабатывания domReady/domLoad?
                                          +3
                                          И какой смысл такого теста, вы бы набросали в базу каждой CMS к примеру несколько десятков тысяч постов, комментов и т.п. А так получилось, что CMS у которой меньше функционала, та и победила. Да и обычно самые веселые косяки производительности вылазят когда, уже база содержит большое количество контента.
                                            –1
                                            Да, я в статье отметил, что по мере расширения базы данных (кол-ва материалов на сайте) ситуация может существенно измениться.
                                              0
                                              Ну я думаю мало кого интересует эксплуатация CMS с одной тестовой страничкой. Вот как раз исследование скорости работы с разным количеством контента — было бы интересно. Можно к примеру ограничиться одним модулем посты/новости, и посмотреть скорость на разном количестве записей.
                                            +1
                                            Спасибо.
                                            Провел тестирование и своей CMS, сделал обобщающие графики.
                                            Несмотря на наличие расширенного функционала моя CMS оказалась быстрее описанной из-за особенностей архитектуры и голого PHP.
                                            Несмотря на скорость (и это без кеширования), это не делает её лучшей.
                                              +2
                                              вот эту копипасту
                                                  public static function getInstance() {
                                                      if(is_null(self::$instance)) {
                                                          self::$instance = new self();
                                                      }
                                                      return self::$instance;
                                                  }
                                              


                                              неплохо было бы сократить, используя позднее статическое связывание
                                                0
                                                Да, я уже над этим задумался. Но решение есть несколько иное — т.к. все одиночки наследуют \engine\singleton — внедрить в него тот самый статический getInstance() и записывать в локальную статическую переменную внутри singleton ссылку на инициированный класс. Возможно, ваше решение лучше(если есть что «почитать» или пример — пришлите в л.с.). Спасибо.
                                                  +1
                                                  Ну например:
                                                  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() {}
                                                  }
                                                  
                                                    0
                                                    Мой вариант был чутку иным:
                                                    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 раз.
                                                      0
                                                      Может я совсем туп, но я не понял…
                                                      Можете пояснить как это должно работать?
                                                        0
                                                        А что тут пояснять то? Запрещаем инстанцирование из вне класса (не только new но и десериализацию и т.д.) путем добавления модификатора доступа protected. Так же инстанс класса будет лежать в статической переменной $instance которая так же не доступна из вне. Если переменная пустая — надо создать инстанс класса. Тут на помощь приходит позднее статическое связывание — static указывает на класс, из под которого мы обращались к статическому методу. Вызываем конструктор (потому что изнутри можно) и возвращаем инстанс.
                                                          0
                                                          Как раз это понятно — классическая реализация синглтона на PHP.
                                                          Зачем static $instance = null; и чем это лучше варианта с self::?
                                                            0
                                                            Потому что можно. Зачем захламлять базовый класс лишними приватными статическими свойствами? Реализация выходит чище и более универсальной. Можно потом в трейт запихнуть и вообще отказаться от излишнего наследования.
                                                              0
                                                              А, ну то-есть это именно для «более лучшего»™ стиля кода? Ну тоже неплохо. Спасибо. Поправлю сегодня у себя.
                                                              0
                                                              Это лучше так же тем, что для автокомплита в IDE будет достаточно следующего phpdoc: @ return static, а в случае описанным мной выше придется достаточно упорно поизвращаться.
                                                                0
                                                                Suntechnic не про тот static. Ему любопытно почему локальной статической переменной а не приватным статическим свойством.
                                                                  0
                                                                  Да, именно это. Еще раз, пользуясь случаем, спасибо за разъяснение.
                                                                  Век живи — век учись…
                                                        +1
                                                        Дык Singleton давно уж не в почете, лет как 5.
                                                        DI, IoC и все такое. Возможно стоит вовсе пересмотреть отношение к этому паттерну.
                                                      +1
                                                      Мне чем то напомнил ваш тест вот это vanilla js
                                                      По крайней мере в таком же стиле все описано.
                                                      А если серьезно многие CMS медленно работают в единичном запросе, но зато выигрывают при реальном использовании сайта, когда запросов 100 и 1000 в миниту или даже секунду. Начинает работать кеширование, некоторые данные хранятся в оперативной памяти и тем самым доступ к ним можно получить намного быстрее чем из базы данных.
                                                      Вместо того чтобы мерить один скрипт вы бы посчитали бы количество запросов к базе, нагрузку на базу если разом сделать 1000 запросов одной страницы. Если разом запросить 1000 разных страниц, под разными пользователями. Вот тогда и смотрите что будет быстрее работать.
                                                      А эти исследования чушь, бессмыслица полная.
                                                        0
                                                        С UMI в целом все более-менее прогнозируемо, там сферическое ООП на ООП сидит в вакууме и ООП погоняет.

                                                        Сравнение через выполнение index.php не слишком корректно — у разных CMS в демо-сайтах разное количество модулей прогружается.
                                                        Т.е. тот же битрикс интересно было бы потестировать хотя бы на инфоблоках с большим количеством вложенных категорий с кучей доп. параметров и счетчиком элементов в категории.
                                                        Т.е. сравнивать на конкретных примерах — интернет-магазин, новостной сайт и т.д. и т.п.
                                                          –1
                                                          Да, соглашусь у многих после «стандартной установки» сайт уже набит материалами и кучей модулей(bitrix, umi) — об аутентичности для всех систем я не заявлял. И да, все выбранные cms обладали более-менее схожим функционалом (интернет магазинов не было в тестировании).
                                                          Но довести все 10 систем до «одинаково равного уровня наполнения» — очень затратно и опять же вызовет столько же вопросов о том, действительно ли все системы находились в равных условиях.
                                                          Как говориться — не важно как тестируют, важно как считают :)
                                                            +1
                                                            А какой смысл в этом тесте? Сравнивать, кто сильнее — слон или кит?
                                                          +2
                                                          Оу…
                                                          Я тут пилю вот прямо сейчас решение для одной CMS заменяющее кое-какой стандартный функционал. И ломаю голову над тем, как же объективно сравнить производительность моего решения со штатным в рамках одной CMS.
                                                          Банальный пример — при выводе списка новостей, может понадобиться только заголовок новости, а может понадобиться и кусок текст в качестве стрейпа. Штатное решение всегда извлекает текст, а мое только по необходимости. (искусственный пример — по факту всё сложнее, но смысл тот же)
                                                          В каком режиме сравнивать? Если с извлечением и обработкой текста производительность похожая, а если нет — я рву штатное в клочья. Понятно, что нужно тестить оба случая, но в каком процентном соотношении смешать результат? А ведь таких вопросов даже при выводе просто списка новостей, у меня уже под дюжину.
                                                          А тут вононо как оказывается надо. Автор, ты бог бенчмаркостроения.
                                                            0
                                                            Мауриц Эшер позавидовал бы автору этой картинки

                                                            image

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

                                                            Самое читаемое