Ars Longa, Vita Brevis » benchmark http://blog.sjinks.pro Quod scripsi, scripsi Mon, 06 Feb 2012 17:56:02 +0000 en hourly 1 WP Super Cache vs MaxSite Cache: часть 1 http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/ http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/#comments Fri, 13 Nov 2009 23:17:34 +0000 Vladimir http://blog.sjinks.pro/?p=689 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Тест страничных кэшей на виртуальном сервере абсолютного чайника

После того, как MAX’у не понравился тест с участием MaxSite Cache, я решил несколько видоизменить методику тестирования.

На этот раз я тестировал только два кэша: и Lite.

Так как по словам MAX’а в реальности все ставится «из коробки», я взял виртуальный сервер (512 MiB RAM, 10 GB HD, Intel Xeon X3320 (1 ядро), 2.5 GHz), на который поставил Ubuntu 8.04 LTS Server Edition. Затем поставил  (2.2.8-1ubuntu0), PHP (5.2.4-2ubuntu5.6) и MySQL (5.0.51a-3ubuntu5.4). Конфигурационные файлы брались «из коробки» (только для пришлось включить mod_rewrite), в системной конфигурации абсолютно ничего не менялось. VDS абсолютного «чайника». Для мониторинга ресурсов системы установил munin (он рисует такие красивые графики).

Кому интересно, VDS конфигурировался так:

wget http://ubuntu-releases.eecs.wsu.edu/hardy/ubuntu-8.04.3-server-i386.iso
VBoxManage registerimage dvd /home/user1/ubuntu-8.04.3-server-i386.iso
VBoxManage createhd --filename TestVDS-HD1 --size 10240 --remember
VBoxManage createvm --name TestVDS --register
VBoxManage modifyvm TestVDS \
    --ostype Ubuntu \
    --memory 512 --vram 1 \
    --acpi on --ioapic off --pae off --hwvirtex on --nestedpaging on \
    --boot1 dvd \
    --sata on --sataport1 TestVDS-HD1 \
    --dvd /home/user1/ubuntu-8.04.3-server-i386.iso \
    --floppy disabled \
    --nic1 nat \
    --audio none

VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/Protocol" TCP
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/GuestPort" 80
VBoxManage setextradata TestVDS "VBoxInternal/Devices/pcnet/0/LUN#0/Config/guesthttp/HostPort" 8080

Затем я поставил  2.8.5 с официального сайта, импортировал в блог порядка 800 статей среднего размера (авторство статей не моё, так что выложить не могу).

Вместо Apache Bench я использовал Siege, обращение производилось ко всем страницам сайта в случайном порядке (вероятность обращения к заданной странице задавалась количеством её повторений в файле с адресами). Тестирование каждого варианта (WP Super Cache и MaxSite Cache) проводилось по 45 минут — 30 минут при низкой нагрузке и 15 минут при высокой (увы, трафик не безлимитный, и раскидываться гигабайтами трафика для теста возможности пока нет). Это имитировало постепенный наплыв пользователей на сайт. Специфика теста такова, что новый запрос не выполнялся до тех пор, пока не завершался предыдущий.

Одновременно к страницам обращалось 30 пользователей (Apache просто больше не выдерживает). Между тестами системе перезагружалась (на всякий случай). Виртуальный сервер и сервер, с которого осуществлялось тестирование, были, естественно, разными; соединены гигабитным каналом.

Результаты получились очень интересными: MaxSite Cache Lite строит кэш несколько быстрее, чем WP Super Cache (у MaxSite Cache более простая логика работы). WP Super Cache создаёт более сильную нагрузку на диск (так как файлы разбрасываются по множеству каталогов, а не кидаются в один) и, за счёт этого, чуть большую нагрузку на процессор (если сравнивать по значению idle time). Но при этом у WP Super Cache больший коэффициент параллельности (обслуживает большее число запросов одновременно).

Но при отдаче кэша и с повышением нагрузки результат меняется: WP Super Cache отдаёт данные быстрее и, как результат, обслуживает большее количество клиентов. Потребление памяти при этом чуть меньше, но загрузка процессора чуть больше. Вообще картину очень сильно портил munin — нагрузка, им создаваемая, вносила существенные погрешности в измерения (было видно в top).

Построение кэша
  WP Super Cache MaxSite Cache
Количество транзакций 91,755 95,028
Объём данных, МБ 2,160.51 2,240.59
Среднее время ответа, с 0.05 0.04
Частота транзакций в секунду 50.97 52.79
Пропускная способность, МБ/с 1.20 1.24
Коэффициент параллельности 2.58 2.21
Максимальная длина транзакции, с 20.93 19.10
Минимальная длина транзакции, с 0.00 0.00
Использование кэша
  WP Super Cache MaxSite Cache
Количество транзакций 219,761 206,949
Объём данных, МБ 5,129.06 4,880.30
Среднее время ответа, с 0.07 0.09
Частота транзакций в секунду 244.29 229.92
Пропускная способность, МБ/с 5.70 5.42
Коэффициент параллельности 27.89 21.58
Максимальная длина транзакции, с 21.96 21.58
Минимальная длина транзакции, с 0.00 0.00

Краткие выводы: в плане построения кэша у MaxSite Cache Lite выше, что объясняется простотой его логики. Но при нагрузке и построенном кэше WP Super Cache обладает более высокой производительностью, так как web-сервер способен отдавать закэшированные данные без привлечения PHP. При одинаковом количестве запросов в секунду под нагрузкой WP Super Cache демонстрирует меньшее потребление памяти и нагрузку на процессор. При средней нагрузке на систему оба кэша ведут себя примерно одинаково — разница в потреблении памяти и нагрузке незаметна.

В следующей части: тест WP Super Cache и MaxSite Cache на грамотно настроенном сервере.

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/wordpress/689-wp-super-cache-vs-maxsite-cache-part-1/feed/ 9 OpenMP на многоядерном процессоре и криптография http://blog.sjinks.pro/openmp/522-openmp-on-multicore-cpu-and-cryptography/ http://blog.sjinks.pro/openmp/522-openmp-on-multicore-cpu-and-cryptography/#comments Sat, 04 Apr 2009 01:36:56 +0000 Vladimir http://blog.sjinks.pro/?p=522 © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Практический пример использования

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

Использование OpenMP должно приводить к увеличению производительности за счет того, что программа (по крайней мере, её параллельные участки) выполняется не на одном процессоре, а на всех доступных. Процесс распределения потоков по процессорам можно контролировать.

В соответствии с законом Амдаля–Уэра (увеличение количества вычислителей приводит к ограничению роста производительности), имея четыре процессора, мы не получим четырёхкратное увеличение производительности. К тому же затраты на синхронизацию и управление потоками сказываются на производительности не лучшим образом. Да и увеличение вычислительной мощности в N раз не приводит к аналогичному росту скорости обращения к памяти.

Я решил проверить, каким будет прирост производительности параллельного шифрования в режиме ECB у алгоритма шифрования ГОСТ 28147—89 на четырёхядерном процессоре.

Операция зашифрования по ГОСТ 28147—89 сама по себе не может быть распараллелена (да и есть ли смысл?). Но так как в режиме операция зашифрования одного блока не зависит от остальных блоков, то процесс можно распараллелить.

Цикл зашифрования выглядит следующим образом (для краткости я не привожу вспомогательные таблицы):

uint_fast32_t gost_data_1[256];
uint_fast32_t gost_data_2[256];
uint_fast32_t gost_data_3[256];
uint_fast32_t gost_data_4[256];

union gostrec_t {
    uint8_t x[8];
    uint32_t y[2];
};

void do_encode(union gostrec_t* const buf, const uint32_t* const key)
{
    const uint32_t* k = key;
    uint_fast32_t a = buf->y[0];
    uint_fast32_t b = buf->y[1];
    uint_fast32_t t;

    for (uint_fast32_t i=0; i<=11; ++i) {
        if (0 == (i & 3)) k = key;

        t  = a + k[0];
        b ^= gost_data_1[(uint8_t)t] ^ gost_data_2[(uint8_t)(t >> 8)] ^ gost_data_3[(uint8_t)(t >> 16)] ^ gost_data_4[(uint8_t)(t >> 24)];

        t = b + k[1];
        a ^= gost_data_1[(uint8_t)t] ^ gost_data_2[(uint8_t)(t >> 8)] ^ gost_data_3[(uint8_t)(t >> 16)] ^ gost_data_4[(uint8_t)(t >> 24)];

        k += 2;
    }

    k = key + 8;
    for (uint_fast32_t i=0; i<=3; ++i) {
        k -= 2;

        t  = a + k[1];
        b ^= gost_data_1[(uint8_t)t] ^ gost_data_2[(uint8_t)(t >> 8)] ^ gost_data_3[(uint8_t)(t >> 16)] ^ gost_data_4[(uint8_t)(t >> 24)];

        t = b + k[0];
        a ^= gost_data_1[(uint8_t)t] ^ gost_data_2[(uint8_t)(t >> 8)] ^ gost_data_3[(uint8_t)(t >> 16)] ^ gost_data_4[(uint8_t)(t >> 24)];
    }

    buf->y[0] = (uint32_t)b;
    buf->y[1] = (uint32_t)a;
}

Зашифрование в режиме ECB выглядит так:

void encode(uint8_t* buf, uint32_t len, const uint32_t* key)
{
    for (int32_t i=0; i<(int32_t)len; i+=sizeof(union gostrec_t)) {
        do_encode((union gostrec_t* const)(buf+i), key);
    }
}

Длина явно приводится к знаковому типу для облегчения переноса на OpenMP (в спецификации есть требование, чтобы счетчики циклов были знаковыми).

Параллельная версия процедуры зашифрования будет выглядеть так:

void encode_omp(uint8_t* buf, uint32_t len, const uint32_t* key)
{
    #pragma omp parallel
    {
        #pragma omp for schedule(static) nowait
        for (int32_t i=0; i<(int32_t)len; i+=sizeof(union gostrec_t)) {
            do_encode((union gostrec_t* const)(buf+i), key);
        }
    }
}

Makefile:

CC=gcc
CFLAGS=-O3 -fopenmp -march=native -fstrict-aliasing -std=gnu99 -Wall -Wextra -Wno-unused-parameter -Wstrict-aliasing=1 -Wdisabled-optimization
CFLAGS_PGEN=-g3 -pg -fprofile-arcs -ftest-coverage -fprofile-generate
CFLAGS_PUSE=-fomit-frame-pointer -fprofile-use
LDFLAGS=-fopenmp
LDFLAGS_PGEN=-fprofile-generate

all: gost
        ./gost
        $(CC) $(CFLAGS) $(LDFLAGS) $(CFLAGS_PUSE) main.c gost.c -o gost

gost: main.o gost.o
        $(CC) $(LDFLAGS) $(LDFLAGS_PGEN) $^ -o $@

main.o: main.c gost.h
        $(CC) $(CFLAGS) $(CFLAGS_PGEN) -c $*.c

gost.o: gost.c gost.h
        $(CC) $(CFLAGS) $(CFLAGS_PGEN) -c $*.c

clean:
        -rm -f *.o gost *.gcda *.gcno

.PHONY: all clean

Производительность измерялась путем многократного прогона операции зашифрования над стомегабайтным (точнее, стомебибайтным) буфером.

Получились весьма интересные результаты:

  Min Max Avg
Parallel 1.43 1.46 1.44
Serial 1.39 1.42 1.41

Параллельная версия алгоритма не только не даёт прироста в производительности, но еще и проигрывает последовательной версии!

Так бы и считал, если бы во время тестирования альтернативной версии не заметил, что параллельная версия выполняется быстрее. Мораль: читайте маны.

Дело в том, что время измерялось следующим образом:

    start = clock();
    func(buf, n, key);
    stop = clock();
    x = (double)(stop - start) / CLOCKS_PER_SEC;

Но CLOCKS_PER_SEC не учитывает, что у нас четыре ядра, а не одно. Или как раз-таки учитывает. И вообще хз. Я так понял, что на выходе я получаю время, которое понадобилось бы процессору на выполнение задачи, если бы он был один. Тёмный лес.

UPD: POSIX requires that CLOCKS_PER_SEC equals 1000000 independent of the actual resolution.

Как правильно:

    gettimeofday(&start, NULL);
    func(buf, n, key);
    gettimeofday(&stop, NULL);
    x = (1000000.0f*(stop.tv_sec - start.tv_sec) + (stop.tv_usec - start.tv_usec))/1000000;

Итак, что получилось на четырёх ядрах:

  Min Max Avg
Parallel 0.365861 0.408662 0.371971
Serial 1.406327 1.418306 1.412239

Что характерно, в случае с одним процессором оба способа измерения времени работают примерно одинаково, так что будем считать, что в статье "Практическая польза fast-типов" я не сильно наврал со скоростью.

Когда я неудачно измерял время выполнения кода, я думал, что причина неудачи в том, что кэш процессора не резиновый: как-никак буфер для зашифрования 100 мебибайт, потоки берут код из совершенно разных участков памяти, процедура зашифрования активно использует 4 кибибайта таблиц…

Тогда я написал такую процедуру зашифрования, рассчитанную на четыре ядра:

void encode_omp(uint8_t* buf, uint32_t len, const uint32_t* key)
{
    #pragma omp parallel sections shared(buf, key, len)
    {
        #pragma omp section
        for (int32_t i=0; i<(int32_t)len; i+=4*sizeof(union gostrec_t)) {
            do_encode((union gostrec_t* const)&buf[i], key);
        }

        #pragma omp section
        for (int32_t i=sizeof(union gostrec_t); i<(int32_t)len; i+=4*sizeof(union gostrec_t)) {
            do_encode((union gostrec_t* const)&buf[i], key);
        }

        #pragma omp section
        for (int32_t i=2*sizeof(union gostrec_t); i<(int32_t)len; i+=4*sizeof(union gostrec_t)) {
            do_encode((union gostrec_t* const)&buf[i], key);
        }

        #pragma omp section
        for (int32_t i=3*sizeof(union gostrec_t); i<(int32_t)len; i+=4*sizeof(union gostrec_t)) {
            do_encode((union gostrec_t* const)&buf[i], key);
        }
    }
}

Идея в том, что если потоки выполняются с примерно одинаковой скоростью, возможно улучшить локальность данных в кэше процессора (код, скорее, представлял proof of concept, ибо не учитывает целый ряд факторов).

  Min Max Avg
Parallel Sections 0.375868 0.404222 0.384918

Результат с использованием секций получился чуть-чуть хуже.

Выигрыш в производительности на четырёх ядрах составил 380% — не так уж и плохо (особенно если считать, что основной целью статьи было показать, что параллельность — это не всегда хорошо).

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/openmp/522-openmp-on-multicore-cpu-and-cryptography/feed/ 13 MySQL и скорость выполнения INSERT для разных типов таблиц http://blog.sjinks.pro/mysql/44-mysql-insert-speed-for-different-storage-engines/ http://blog.sjinks.pro/mysql/44-mysql-insert-speed-for-different-storage-engines/#comments Thu, 20 Mar 2008 21:57:09 +0000 Vladimir http://blog.sjinks.pro/mysql/44-mysql-insert-speed-for-different-storage-engines/ © 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> Сравнение скорости выполнения INSERT/INSERT DELAYED для таблиц типа (MEMORY), и

Я сейчас работаю над очень интересным проектом, который, как надеется заказчик, составит серьёзную конкуренцию Google Analytics. Но речь не об этом. Разбираясь с архитектурой системы, я обнаружил весьма интересную деталь: 8 гигабайт памяти сервера отдается под несколько таблиц типа HEAP. Так как HEAP-таблицы хранятся в исключительно в памяти, то операция вставки (INSERT) должна выполняться очень быстро, так как временные затраты, связанные с перемещением головок диска и физической записью, отсутствуют. Я решил найти подтверждение этой теории. Google is your friend, и я довольно быстро нашел статью MySQL Engine INSERT speed.

Меня несколько смутили результаты, приведённые автором:

  • MyISAM (с DELAY_KEY_WRITE=ALL): 33 000 INSERT/сек
  • InnoDB: 24 700 INSERT/сек
  • MEMORY: 64 000 INSERT/сек

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

Первыми возникшими вопросами были:

  1. Какой тип вставки использовался для MyISAM/InnoDB-таблиц — INSERT или INSERT DELAYED?
  2. Каким образом вставлялись данные — построчно или блочно (extended insert)?
  3. Значение AUTOCOMMIT при работе с таблицей InnoDB.

Об этом оставалось только гадать, поэтому я решил повторить этот эксперимент.

Методика эксперимента:
Создаются три таблицы:

CREATE TABLE `test0` (
    `field` INTEGER UNSIGNED NOT NULL
) TYPE=HEAP;

CREATE TABLE `test1` (
    `field` INTEGER UNSIGNED NOT NULL
) TYPE=InnoDB;

CREATE TABLE `test2` (
    `field` INTEGER UNSIGNED NOT NULL
) TYPE=MyISAM DELAY_KEY_WRITE=1;

Перед началом эксперимента выполнялась команда

SET AUTOCOMMIT=0

Затем в цикле в таблицу вставлялись случайно сгенерированные данные (компьютер, на котором проводился эксперимент, был слабый, поэтому я ограничился тридцатью тысячами записями). После цикла выполнялся COMMIT. Скрипт выполнялся 10 раз, бралось среднее время.

Исходный текст скрипта:

<?php
    set_time_limit(0);

    function microtime_float()
    {
        list($usec, $sec) = explode(" ", microtime());
        return (float)$usec + (float)$sec;
    }


    $link = mysql_connect('localhost', 'root', '');
    mysql_select_db('test', $link);

    $schema = "CREATE TABLE `test` (`field` INTEGER UNSIGNED NOT NULL)";
    $engines = array(
        ' TYPE=HEAP',
        ' TYPE=InnoDB',
        ' DELAY_KEY_WRITE = 1 TYPE=MyISAM'
    );

    $inserts = array(
        '',
        '',
        'DELAYED',
    );

    mysql_query("DROP TABLE IF EXISTS `test0`, `test1`, `test2`");
    mysql_query("SET AUTOCOMMIT=0");

    for ($i=0; $i<count($engines); ++$i) {
        $query = preg_replace('/`test`/', "`test{$i}`", $schema) . $engines[$i];
        mysql_query($query);
        mysql_query("COMMIT", $link);

        $start = microtime_float();
        for ($j=0; $j<30000; ++$j) {
            $val = mt_rand();
            mysql_query("INSERT {$inserts[$i]} INTO `test{$i}` (`field`) VALUES({$val})", $link);
        }

        mysql_query("COMMIT", $link);
        $end = microtime_float();
        print $end - $start . "\n";
    }

    mysql_close($link);
?>

У меня получились такие результаты (я привожу относительную — относительно таблиц типа HEAP — скорость):

  HEAP InnoDB MyISAM
INSERT 1.000 1.277 1.162
INSERT DELAYED 2.125 0.998

Эксперимент показал, что разница по скорости между INSERT DELAYED для таблицы MyISAM и INSERT для таблицы HEAP очень незначительна. Таблицы InnoDB действительно оказались медленнее, но не сильно. Большую роль здесь могла сыграть «слабость» тестового компьютера и значение переменной innodb_flush_log_at_trx_commit. Вдобавок, MyISAM был сконфигурирован очень даже хорошо, в то время как InnoDB использовал практически значения по умолчанию (мне редко приходится пользоваться таблицами InnoDB, поэтому тонкой настройкой я не занимался). Тем не менее, результаты проведенного мной эксперимента совсем не согласуются с данными, приведёнными в исходной статье. Кто же из нас прав?

© 2012 Ars Longa, Vita Brevis. Все права защищены. Перепубликация материалов без разрешения автора запрещена.

При использовании материалов блога наличие активной не закрытой от индексирования ссылки на источник обязательно.

]]> http://blog.sjinks.pro/mysql/44-mysql-insert-speed-for-different-storage-engines/feed/ 4