Тестирование производительности VDS

    Усиленно подбираю себе VDS — задумался над вопросом сравнения производительности.

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


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

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

    Однако я подумал воспользоваться еще одним способом. Есть CMS, которая генерирует некоторые страницы сайта n секунд. Я написал коротенький скрипт, который запрашивает 10 одинаковых страниц с разных хостов, и затем обрабатывает результат. Здесь самое интересное — лично я не вполне уверен в правильности и адекватности методики, поэтому приведу исходники скриптов:

    Скрипт disp.php — туннель для AJAX, я решил не париться с кросдоменным AJAX'ом :)

    <? print file_get_contents($_SERVER["QUERY_STRING"]) * 1000; ?>

    Скрипт exec.php — запускает основной скрипт CMS, эмулируя обращение, измеряет время обращения и выводит его

    <?

    $time = microtime(1);
    // эмуляция обычного HTTP запроса
    file_get_contents("http://{$_SERVER["HTTP_HOST"]}/АДРЕС");
    print microtime(1) - $time;

    ?>


    Собственно, самый главный скрипт находится по адресу test.osmio.ru/disp.html — весь код на JavaScript, исходники открыты.

    Лично я вижу несколько потенциально «скользких» мест:
    1. Если один скрипт еще не отработал, а новый запрос уже пришел — сервер начинает грузиться сильнее, но от этого спасет галочка синхронных запросов
    2. Скрипт не измеряет полное время запроса, хотя, возможно, следовало бы — все сервера отвечают с разной задержкой… Но я сознательно не включил это в расчет, т.к. каналы между серверами могут идти как угодно, в том числе и через Европу — и такое бывает, что два соседних ДЦ в Мск гоняют траф окольными путями.
    3. HTTP запрос в exec.php — несмотря на то, что он идет на тот же хост

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

    Конфигурации у серверов следующие:
    • vds-dbbb.1gb.ru — 1GB.ru, 500MHz, 384MB, OpenVZ, Gentoo
    • cms.dis.dj — Infobox.ru, 333MHz, 512MB, HyperV, Debian5
    • 89.188.123.24 — Ruweb.net, 2000MHz, 1536MB, VDSManager, FreeBSD6

    У меня замерились следующие значения:
    Хост Среднее Отклонение Мин Макс 0 1 2 3 4 5 6 7 8 9
    vds-dbbb.1gb.ru 156 44 (28%) 128 282 136 138 131 282 137 134 134 133 144 128
    cms.dis.dj 1294 60 (5%) 1234 1462 1275 1291 1279 1259 1234 1462 1282 1269 1262 1316
    89.188.123.24 441 15 (3%) 417 460 451 420 452 456 445 460 417 445 420 443

    Я еще раз повторяю, что методология не факт, что адекватная действительности, но некоторые выводы я все же сделаю:
    • 1GB нехило колбасит, хотя значения, в основном, минимальные
    • Infobox безбожно тормозит — там послабже процессор и принципиально другая технология виртуализации, но не настолько же
    • Ruweb очень стабилен и примерно между 1GB и ISPServer

    Результаты тестов ubench:
    • Infobox
      Ubench CPU: 27692
      Ubench MEM: 19291
      Ubench AVG: 23491
    • 1GB
      Ubench CPU: 55762
      Ubench MEM: 44521
      Ubench AVG: 50141
    • Ruweb — по цифрам машина зло, но она и должна быть мощнее, заявленные характеристики на голову выше остальных
      Ubench CPU: 600191
      Ubench MEM: 269780
      Ubench AVG: 434985

    Выводы — не такая и слабая VDSка у Infobox, даже несмотря на меньшую частоту — она вполне конкурирует с ISPServer. Однако время генерации заметно большее. Я полагаю, что это связано с настройками софта. Здесь следует заметить, что везде, кроме 1GB стоит ISPManager с настроенными по-умолчанию Apache, PHP5 и т.д. Также следует заметить, что есть определенная корреляция между значениями ubench и тем, что намерил мой тестер.

    UPD. У ISPServer кончился тестовый период, и т.к. его результат был не особо хорошим при довольно внушительной цене за хостинг — из расчета я его исключил.
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

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

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

      0
      Не забывайте, что самое страшное по производительности — запросы к БД
      Поэтому очень важна серверная часть тех страниц, которые запрашиваются
        0
        Естественно. Но в случае измерения вторым способом мы получаем суммарное время с учетом всего.
        0
        а исходя из чего вы infobox приравняли к ispserver?
          0
          Только исходя из результата ubench.
          0
          Брал раньше вдску у infobox'a, стояла cent os 4.7 final. Мне не понравилось, слишком много тормозов и простейшие команды выполнялись оч долго… С недавних пор у них вдс стали крутится на Hyper-V, раньше юзалась технология OpenVZ…
            0
            У меня как раз Hyper-V технология. И все равно какие-то тормоза.
              0
              Мораль — если на куске говна пускать OpenVz или Hyper-V, то все равно буду тормоза
              Нечего экономить на железе!
            0
            На самом деле не очень корректное измерение. Зачем тут AJAX? Крутое слово вот и нужно это пихать во все дыры ;) Он тут абсолютно бесполезен, почему я думаю ты и сам уже догадался.

            А по сути идет измерение времение генерации страниц и доставка их до сервера, где запускается exec.php. А скорости между серверами всегда будут значительно выше, чем до клиента с его проблемами на последней миле, так что в этом отношении тест синтетический и не отражает реальной ситуации клиент-сервер.
              0
              AJAX был нужен только чтобы плавно показать процесс опроса — я пробовал включать ob_implicit_flush и пользовать multi_curl, но страница, почему-то, все равно дожидалась конца работы всех запросов и только тогда уходила в браузер — т.е. пару минут «оператор» видел белый экран, а потом «оп» и вся страница целиком.

              Насчет синтетики не спорю, но в данном случае тестировался не канал «клиент-сервер», а именно генерящий страницу сервер.
                0
                Ну так нужно ob_flush() и flush() делать ;)
                  0
                  Ну вообще-то функция ob_implicit_flush выключает буферизацию и любой print|echo и иже с ними идут сразу на вывод. Но я все равно для надежности делал flush, не помогло почему-то… разбираться не стал — просто сделал AJAX'ом…
                    0
                    Эээ… вроде вызваный без флагов он его как раз включает.
                    0
                    Для максимально надежного отключения буферизации на любом уровне, я использую такой код:
                    @apache_setenv('no-gzip', 1);
                    @ini_set('zlib.output_compression', 0);
                    @ini_set('implicit_flush', 1);
                    for ($i = 0; $i < ob_get_level(); $i++) { ob_end_flush(); }
                    ob_implicit_flush(1);

                    помогает. А почему убрали ISPServer?
                      0
                      Ну, т.к. RuWeb работает на той же платформе, ресурсов дает больше, а стоит меньше, и явно выигрывает по производительности — ISPServer был «отстранен», плюс там тестовый период рано кончился.
              0
              К чему квантовая попугаелогия, если есть ab (apache benchmark) для одной страницы и много разных инструментов вроде siege для эмуляции серфинга с загрузкой css, картинок и прочего? Если тест проводится издалека, то дополнительно взять средний пинг до сервера, отнять от результатов — получится реальное время генерации страницы, без всяких сомнений «правильно ли считает самописный бенчмарк».

              Кстати, первый из таблицы от меня вообще не доступен.
                0
                Там площадки отмирают потихоньку — тестовые периоды кончаются… Насчет бенчмарков — в комментариях я как раз и ждал подобных предложений, потому как я про два ваших бенча не знал… Спасибо за совет.
                  0
                  Не знать ab? )) Это же наипервейшая мерялка! Кстати на фряхе с ним есть небольшой косячок alekciy.livejournal.com/1334.html

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

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