?

Log in

No account? Create an account
 
 
20 Апрель 2013 @ 19:07
Работа TrackStudio на многоядерных CPU - история вопроса  
Когда-то давно (2001-2004 годы) TrackStudio все данных хранила в БД, для выборок использовала сложные SQL-запросы и практически ничего не хранила в памяти. Эти версии могли в полной мере использовать потенциал многоядерных CPU, но массовых многоядерных CPU тогда не существовало, а даже двухядерные сервера были весьма дорогими.

К 2003-2004 годам мы уперлись в производительность СУБД, для поддержки иерархии задач и нашей модели прав доступа требовалось буквально "бомбардировать" СУБД SQL запросами, СУБД не справлялись. Подробнее об этом я уже писал.

Тогда эту проблему решили путем создания внутренних кешей весьма сложной структуры буквально для всего, доступ к этим кешам обложили глобальными блокировками. На тот момент это было хорошее решение:
- многопроцессорных серверов все равно было мало, причем "много" часто означало два.
- использование локальных кешей позволило значительно улучшить производительность.

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

Наконец возникла задача, которая не решалась путем оптимизации последовательного кода либо путем распараллеливания отдельных участков. Возможных направлений решения было 3:
1) Оставляем все наши кеши, но (долго и нудно) переписываем ядро системы, делаем его многопоточным.
2) Убираем наши кеши, запросы транслируем в реляционную СУБД напрямую. Раз нет наших кешей - не нужно ничего блокировать, многопоточность получается автоматом. Даже если скорость выполнения одного потока несколько уменьшится, то за счет большего количества потоков можно надеяться получить ускорение работы системы.
3) Аналогично (2), только вместо реляционных СУБД используем нереляционные. На этой волне потратили какое-то время на анализ NoSQL, я даже как-то краткий обзор писал. Хотя тут нас ждут проблемы с хранением  наших сложных структур данных, но NoSQL СУБД могут обеспечить большую скорость при выполнении простых запросов, десятки тысяч запросов в секунду.

Все решил простой эксперимент: мы вставили в исходники наших методов "получить предков узла" и "получить потомков узла" счетчики и попробовали посмотреть в TrackStudio список задач в одном из наших проектов. Значения счетчиков после загрузки одной страницы одним пользователем - 199 тысяч и 367 тысяч, при этом время загрузки страницы в TrackStudio 4 было около 2 сек.

Т.е. если мы убираем наши кеши с их блокировками и перекладываем эту работу на внешнюю СУБД, то она должна обеспечить производительность порядка 280 тысяч запросов вида "получить предков"/"получить потомков" в секунду на каждого работающего пользователя (и запросами этих типов дело не ограничивается) - в общем цифра явно не реальная.

Да, возможно столь большое количество запросов связано с тем, что сейчас для нас эти запросы "дешевы",  мы результаты не кешируем, а значит количество запросов можно сократить. Но для получения адекватного результата требуется сократить количество запросов на 2-3 порядка, что не кажется простой задачей. Кроме того, столь масштабное переписывание привело бы к значительному изменению API системы, на базе которого было написано множество скриптов клиентов, и мы потеряли бы в совместимости.

В итоге пошли по пути 1, результаты тут.
 
 
 
Andrew Karakotov: pic#118747323Andrew Karakotov on Апрель, 24, 2013 06:32 (UTC)
Отличная новость! Ждем релиза :)
(no subject) - ihajitochii on Декабрь, 23, 2013 14:36 (UTC) (Развернуть)
cross_join: pic#123389080cross_join on Май, 27, 2014 07:06 (UTC)
С днем варенья!