Повышение производительности в системах реального времени - PullRequest
0 голосов
/ 28 сентября 2008

Во-первых, я хотел бы установить приемлемую сквозную задержку для системы реального времени в финансовом мире, которая составляет менее 200 мс. Хорошо, вот то, что я после. При проектировании систем реального времени существуют «шаблоны проектирования» (или методы), которые повышают производительность (т. Е. Сокращают время обработки, улучшают масштабируемость и т. Д.).

Примером того, чего я добиваюсь, является использование идентификаторов GUID вместо последовательных номеров для распределения первичных ключей. Обоснование GUID состоит в том, что у обработчиков есть свои собственные генераторы первичного ключа без «консультации» друг с другом. Это позволяет выполнять параллельную обработку и позволяет масштабировать.

Вот еще немного. Я постараюсь добавить в список, когда смогу.

Я кланяюсь коллективной мудрости сообщества. Спасибо, куча!

Ответы [ 4 ]

2 голосов
/ 28 сентября 2008

Для обычной работы системы в режиме реального времени классическое правило - следить за изменчивостью и убивать ее. Реальный жесткий режим в реальном времени означает использование статических расписаний, оптимизированных операционных систем, эффективных драйверов устройств и жестких приоритетов. Никакой динамический или адаптивный материал невозможен, если вы действительно хотите, чтобы вычисление X заканчивалось в пределах известного ограниченного по времени T.

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

1 голос
/ 28 сентября 2008

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

То, что в этом цикле рассчитывается с тем же выходом, что и вне цикла. В качестве основного примера:

for(int i=0;i< x/2; i++)
  //do something

Здесь вы можете безопасно взять х / 2 и рассчитать его до начала цикла и повторно использовать это значение (современные компиляторы теперь заботятся об этих тривиальных оптимизациях)

Чтобы увидеть последствия этого простого правила, я могу привести пример, примененный к запросам к базе данных. Чтобы избежать ВНУТРЕННЕГО СОЕДИНЕНИЯ двух таблиц, чтобы получить высокорекурентный реквизит поля, вы можете нарушить правила нормализации и дублировать его в таблице, относящейся к той, которая имеет значение. Это позволяет избежать повторяющихся операций по объединению таблиц и может высвободить паралелизацию, поскольку только одна из таблиц должна быть заблокирована для транзакций. Пример:

Клиентским запросам к таблице требуется периодическая скидка клиента, но скидка сохраняется в таблице типов клиентов.

1 голос
/ 28 сентября 2008

Вы уже упомянули архитектуру, управляемую событиями, я бы посоветовал вам взглянуть на архитектуру поэтапного управления событиями (SEDA).

Этап, по сути, представляет собой очередь для событий и функцию для обработки события. «Нетрадиционная» вещь в этой архитектуре состоит в том, что каждый этап может быть запущен в своем собственном потоке, а функциям обычно требуется асинхронный ввод-вывод и т. Д. Организация программ таким образом поначалу неудобна, но допускает все виды магии - например, QoS, измененное планирование и т. Д.

См. Диссертацию Уэльса в Беркли и его веб-сайт . Вы также можете взглянуть на проект Минора Гордона (из Кембриджа, Великобритания) под названием yield . У него были очень хорошие результаты. Может показаться, что проект изначально ориентирован на Python, но его можно использовать и для чистого c ++.

0 голосов
/ 05 ноября 2008

Ничего не "исправляйте", если вы точно не знаете, что оно "сломано".

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

...