Тесты mnesia (в задаче обработки котировок)
Модельная задача следующая: обрабатываем пакеты котировок по разным инструментам, формируем из них агрегаты OHLC, пишем их на диск раз в минуту.
Котировка состоит в основном из цены, времени, и кода инструмента, агрегат OHLC - первое, максимальное, минимальное, и последнее значение за период.
Тестируем в условиях 1000 котировок в минуту на инструмент, количество инструментов - параметр, прогоняем на данных за 10 минут, меряем время.
Первый вариант - сделать все на мнезии. Одна транзакция на пакет, для каждой котировки вытягиваем агрегат (из таблицы ram only), обновляем его, пишем обратно, и если требуется (минута переключилась) - пишем на диск (в другую таблицу, которая disk only).
Так как в LJ затрахаешься вставлять экселевский график, даю данные для 100 инструментов. Это 52 секунды.
Но мы умные парни, и кладем в начале транзакции table write lock на таблицу, которая ram only, чтобы mnesia не делала блокировок на каждую запись. Это должно поправить ситуацию. И действительно: 22 сек.
Скрипя зубами, делаем операции над ram-only таблицей "грязными" - на самом деле нам блокировки нужны только при случае, если мы изменяем вторую, disk-only таблицу, чтобы не нарушилась целостность. Получаем: 17,6 сек.
Улучшение небольшое - возникает вопрос, что будет если вообще убрать транзакции, и обойтись только грязными операциями. 16,3
Ну, знаете-ли. В принципе, результат не такой плохой, но признаться я ожидал большего. Чтобы понять, насколько именно я обманут в ожиданиях, делаем так. Убираем нафиг первую ram-only таблицу, заменяя ее на process dictionary. Ничего быстрее для данной цели в Эрланге нет.
Получаем, внимание... 1,2 сек.
Для чистоты эксперимента можно еще попробовать gb_trees, и ets таблицы. И прогнать это все на реально больших количествах инструментов. Что, собственно, я и сделаю. Но одно ясно - для реально частых обновлений, где их скорость критична, использовать mnesia не стоит, я морально не готов жертвовать производительностью в 15 раз на ровном месте.
Котировка состоит в основном из цены, времени, и кода инструмента, агрегат OHLC - первое, максимальное, минимальное, и последнее значение за период.
Тестируем в условиях 1000 котировок в минуту на инструмент, количество инструментов - параметр, прогоняем на данных за 10 минут, меряем время.
Первый вариант - сделать все на мнезии. Одна транзакция на пакет, для каждой котировки вытягиваем агрегат (из таблицы ram only), обновляем его, пишем обратно, и если требуется (минута переключилась) - пишем на диск (в другую таблицу, которая disk only).
Так как в LJ затрахаешься вставлять экселевский график, даю данные для 100 инструментов. Это 52 секунды.
Но мы умные парни, и кладем в начале транзакции table write lock на таблицу, которая ram only, чтобы mnesia не делала блокировок на каждую запись. Это должно поправить ситуацию. И действительно: 22 сек.
Скрипя зубами, делаем операции над ram-only таблицей "грязными" - на самом деле нам блокировки нужны только при случае, если мы изменяем вторую, disk-only таблицу, чтобы не нарушилась целостность. Получаем: 17,6 сек.
Улучшение небольшое - возникает вопрос, что будет если вообще убрать транзакции, и обойтись только грязными операциями. 16,3
Ну, знаете-ли. В принципе, результат не такой плохой, но признаться я ожидал большего. Чтобы понять, насколько именно я обманут в ожиданиях, делаем так. Убираем нафиг первую ram-only таблицу, заменяя ее на process dictionary. Ничего быстрее для данной цели в Эрланге нет.
Получаем, внимание... 1,2 сек.
Для чистоты эксперимента можно еще попробовать gb_trees, и ets таблицы. И прогнать это все на реально больших количествах инструментов. Что, собственно, я и сделаю. Но одно ясно - для реально частых обновлений, где их скорость критична, использовать mnesia не стоит, я морально не готов жертвовать производительностью в 15 раз на ровном месте.