вторник, 24 мая 2011 г.

Диагностика тормозов при разработке торговых систем

Не так давно столкнулась с тем, что задача робота подвисала время от времени при отправке заявок в систему. Стала вылавливать эту "заразу" простым дедовским методом — писать в лог время до и после участков кода, которые вызывали подозрение (в том плане, что могли тормозить).

В результате у меня появилось такое огромное количество участков кода типа: 
DateTimeToString(strDT,'h:m:s.z',ServerDT);
S := Format ('MTS12: Time: Offer FindOrderIdByPriceAndDirection end: %s',[strDT]);
R.fATLibLog(PChar(S),4);

что я потом запарилась анализировать лог. Было вообще непонятно: проблема крылась за пределами тех участков, в которых я ее подозревала.

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

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

Чтобы быть в курсе обновлений блога, подпишитесь на RSS.
Автор: Masha на 17:45
Ярлыки: ,

2 комментария:

  1. Aleks18 июня 2011 г. в 22:55

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

    Я бы на Вашем месте вынес всё это в отдельную функцию, которую можно было бы сделать и помощнее, добавив туда анализатор интервалов вызова, - с коротким названием и одним параметром-ремаркой. Жалко, давно уже не работал с Делфи, как там обстоят нынче дела с рефлексией? Есть возможность стек вызовов полистать, чтобы не писать каждый раз где и что происходит?

    ОтветитьУдалить
  2. Masha19 июня 2011 г. в 01:12

    Спасибо за совет :) Пока, наверное, это для меня не в приоритетах...

    ОтветитьУдалить