Тормоза на Плазе
Atom Ответить
14.09.2011


Поднимаю старую тему, чтобы лишнего не плодить. Библиотека 3.2.11
Два вопроса:
1) Как использовать StrategyLatencyManager? В доках ничего толком не сказано, вроде как все само должно. У стратегии LatencyManager создается автоматически. Но вот массив Orders всегда пуст и самому добавить в него ордеры нельзя. Свойство Latency мэнеджера всегда 0, как и у любой заявки.

2) И без LatencyManager'а видно, что заявки выставляются 5-10 секунд (это через плазу). Как так?


Теги:


Спасибо:




44 Ответов
< 1 2 
Alexander

Фотография
Дата: 20.09.2011
Ответить


FiNick Перейти
Alexander Перейти
Просьба сопровождать коммиты(чек ины) комментариями и проверять перед выкладыванием :)
после последних 2х чек инов плаза работать перестала.


С комментами ступил, буду писать.
На счет не работает: не билдится или рантайм эксепшны? У меня билдится, но на прогоне данные с потока подтягивать не пробовал.
Кстати, какая у вас политика при создании этих PlazaXXXColumns? Надо туда вбивать все колонки какие есть в документации или только самые необходимые?
Я так смотрю колонки многих таблиц не до конца описаны или не описаны вовсе.


Исправил. Не грузились данные.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 20.09.2011
Ответить


FiNick Перейти
Кстати, какая у вас политика при создании этих PlazaXXXColumns? Надо туда вбивать все колонки какие есть в документации или только самые необходимые?
Я так смотрю колонки многих таблиц не до конца описаны или не описаны вовсе.


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

И да, нужно, конечно же, полную проекцию Плаза таблиц.
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Результаты замеров после вчерашних изменений со 100мс.
Всего послал 10 заявок.
Для первой заявки всё происходит максимально долго:

Цитата:
3мс от RegisterOrder до обработчика PlazaTrader.OnRegisterOrder
110мс на _transactionManager.Factory.CreateRegister(order);
5мс на transaction.Set
12мс на SendTransaction


Далее всё быстрее, но.

Цитата:
0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
122мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
4мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
1мс на transaction.Set
0мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
100мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
100мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
1мс на transaction.Set
203мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
34мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
2мс на _transactionManager.Factory.CreateRegister(order);
0мс на transaction.Set
101мс на SendTransaction

0мс от отправки заявки до PlazaTrader.OnRegisterOrder
1мс на _transactionManager.Factory.CreateRegister(order);
1мс на transaction.Set
100мс на SendTransaction


SendTransaction работает медленно, как раз видна дискретность в 100мс.
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Прологировал SendTransaction
Первый запуск:
Цитата:
6мс AddTransaction
45мс SendAsync


Последующие: (где не указан AddTransaction - там 0мс):
Цитата:
42мс SendAsync

204мс SendAsync

24мс SendAsync

1мс AddTransaction
4мс SendAsync

1мс AddTransaction
4мс SendAsync

17мс SendAsync

1мс AddTransaction
4мс SendAsync

33мс SendAsync

100мс SendAsync
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Включил UseLocalProtocol у себя в примере по умолчанию, полное время исполнения OnOrderRegister снизилось до 0-2мс.
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


FiNick Перейти
Кстати, странная фишка: у меня если плаза не подключена проц на 100% забит, подключаю нагрузка до 0-2% падает, отключаю опять 100%.


Исправил, фикс - в исходниках codeplex Cool
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Произвёл замеры на тестовом сервере биржи - 100 заявок.
1) регистрирую время - посылаю заявку
2) получаю ответ от биржи - регистрирую время.

В итоге средняя разница между 2) и 1) составила 140мс (это не с сервера биржи, а с рабочего компа).
Максимальное время - 2148мс, минимальное - 58мс.

Такой всплеск - до 2 секунд был 1 раз, в остальном заявки - до 150мс, пару раз было по 500мс. Первая посланная заявка - 600мс.


Пошёл дальше - посмотрел на среднюю задержку пакетов от меня до биржи - с помощью rts echo. В итоге после 50 тысяч запросов - 105мс средняя задержка канала.


Всё, с тормозами Plaza2, похоже, решено.
Пользуйтесь.

Единственная оставшаяся задача - поддержка 64 бит. Желающих как обычно нет? :)
Спасибо: Ortn

Alexander

Фотография
Дата: 27.09.2011
Ответить


Отправил ещё 400 заявок.

Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды

минимальное - от 31 до 93мс.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 27.09.2011
Ответить


Alexander Перейти
Отправил ещё 400 заявок.

Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды

минимальное - от 31 до 93мс.


Можешь тесты залить так же на КодеПлекс? Даже лучше в качестве примеров. Чтобы в любой момент каждый смог бы проверить свою скорость под нагрузкой.
Спасибо:

FiNick

Фотография
Благотворитель
Дата: 27.09.2011
Ответить


На форуме rts было написано:
Цитата:

Из этого следует несколько выводов:

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

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

б. Обработка таймаута при ожидании на объекте ядра точно также как при Sleep квантуется по 10-15 мс.
Таймаут в 1 мс статистически эквивалентен таймауту в 10 мс. Так устроена ОС Windows.

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

г. Таймаут = 0 в ProcessMessage означает, что один из процессоров или
процессорных ядер будет постоянно загружен обработкой пустого (по большей части) цикла данного потока.

У нас:
Цитата:

1мс AddTransaction
4мс SendAsync

33мс SendAsync

100мс SendAsync


Чем занимается SendAsync столько времени, оно же вроде асинхронная отправка, неужели дожидается какого-то ответа? И плюс почему PollTimeOut влияет на это время, судя по коду там есть TransactionTimeOut для этого (5 сек по умолчанию).
Автор топика
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


FiNick Перейти
На форуме rts было написано:
Цитата:

Из этого следует несколько выводов:

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

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

б. Обработка таймаута при ожидании на объекте ядра точно также как при Sleep квантуется по 10-15 мс.
Таймаут в 1 мс статистически эквивалентен таймауту в 10 мс. Так устроена ОС Windows.

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

г. Таймаут = 0 в ProcessMessage означает, что один из процессоров или
процессорных ядер будет постоянно загружен обработкой пустого (по большей части) цикла данного потока.

У нас:
Цитата:

1мс AddTransaction
4мс SendAsync

33мс SendAsync

100мс SendAsync


Чем занимается SendAsync столько времени, оно же вроде асинхронная отправка, неужели дожидается какого-то ответа? И плюс почему PollTimeOut влияет на это время, судя по коду там есть TransactionTimeOut для этого (5 сек по умолчанию).


Не дожидается похоже. PollTimeOut всё же не влияет, я был не прав.
TransactionTimeOut вообще за другое ответственен, он тут тоже не при чём.

Ещё раз повторюсь - как только сделал через shared memory - всё стало мгновенно.

Потестируйте у себя, интересно сравнить.
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Mikhail Sukhov Перейти
Alexander Перейти
Отправил ещё 400 заявок.

Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды

минимальное - от 31 до 93мс.


Можешь тесты залить так же на КодеПлекс? Даже лучше в качестве примеров. Чтобы в любой момент каждый смог бы проверить свою скорость под нагрузкой.



Они сейчас просто в виде подсчёта разницы DateTime внутри PlazaTrader. Попробую на выходных отрефакторить и выложить, хотя бы в виде диффа.
Спасибо:

FiNick

Фотография
Благотворитель
Дата: 27.09.2011
Ответить


Alexander Перейти
Потестируйте у себя, интересно сравнить.

До включения UseLocalProtocol: RegisterOrder работает в среднем 31 мс (кста, видно что там квант времени 15,625 мс, потому надо пользоваться каким-нибудь Stopwatch и т.п.), latency в среднем 180-200мс
После включения: RegisterOrder работает за 0мс (кроме первого раза), latency в среднем 150-170мс, т.е на эти 30мс меньше стала.
Автор топика
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


FiNick Перейти
Alexander Перейти
Потестируйте у себя, интересно сравнить.

До включения UseLocalProtocol: RegisterOrder работает в среднем 31 мс (кста, видно что там квант времени 15,625 мс, потому надо пользоваться каким-нибудь Stopwatch и т.п.), latency в среднем 180-200мс
После включения: RegisterOrder работает за 0мс (кроме первого раза), latency в среднем 150-170мс, т.е на эти 30мс меньше стала.


Latency как считаете?
Спасибо:

Ortn

Фотография
Дата: 27.09.2011
Ответить


Alexander Перейти
Произвёл замеры на тестовом сервере биржи - 100 заявок.
1) регистрирую время - посылаю заявку
2) получаю ответ от биржи - регистрирую время.

В итоге средняя разница между 2) и 1) составила 140мс (это не с сервера биржи, а с рабочего компа).
Максимальное время - 2148мс, минимальное - 58мс.

Такой всплеск - до 2 секунд был 1 раз, в остальном заявки - до 150мс, пару раз было по 500мс. Первая посланная заявка - 600мс.


Пошёл дальше - посмотрел на среднюю задержку пакетов от меня до биржи - с помощью rts echo. В итоге после 50 тысяч запросов - 105мс средняя задержка канала.


Всё, с тормозами Plaza2, похоже, решено.
Пользуйтесь.

Единственная оставшаяся задача - поддержка 64 бит. Желающих как обычно нет? :)


Очень интересно какие результаты получатся у других людей. Сам проверить не могу т.к. нет доступа по плазе.

ЗЫ Не много не по теме, но может кто знает, насколько трудно получить тестовый доступ к серверу плазы? И можно ли это вообще сейчас сделать, или это только на время тестирования раздавали тестовые логины?
Спасибо:

FiNick

Фотография
Благотворитель
Дата: 27.09.2011
Ответить


Alexander Перейти
FiNick Перейти
Alexander Перейти
Потестируйте у себя, интересно сравнить.

До включения UseLocalProtocol: RegisterOrder работает в среднем 31 мс (кста, видно что там квант времени 15,625 мс, потому надо пользоваться каким-нибудь Stopwatch и т.п.), latency в среднем 180-200мс
После включения: RegisterOrder работает за 0мс (кроме первого раза), latency в среднем 150-170мс, т.е на эти 30мс меньше стала.


Latency как считаете?


Время работы RegisterOrder: тупо DateTime.Now после вызова минус до вызова, а latency это свойство Order.Latency


Цитата:
ЗЫ Не много не по теме, но может кто знает, насколько трудно получить тестовый доступ к серверу плазы?

Очень просто, пишите в техподдержку rts, выдадут.


P.S. Похоже уже можно выпускать релиз 4.0.1 =)
Автор топика
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 27.09.2011
Ответить


Alexander Перейти
Они сейчас просто в виде подсчёта разницы DateTime внутри PlazaTrader. Попробую на выходных отрефакторить и выложить, хотя бы в виде диффа.


А зачем внутрь засовывал? Для замера регистрации достаточно Watch.Do(() => for 1 to 100000 trader.RegisterOrder). Для замера времени движения заявки - Order.Latency.
Спасибо:

Alexander

Фотография
Дата: 27.09.2011
Ответить


Mikhail Sukhov Перейти
Alexander Перейти
Они сейчас просто в виде подсчёта разницы DateTime внутри PlazaTrader. Попробую на выходных отрефакторить и выложить, хотя бы в виде диффа.


А зачем внутрь засовывал? Для замера регистрации достаточно Watch.Do(() => for 1 to 100000 trader.RegisterOrder). Для замера времени движения заявки - Order.Latency.


Намудрил я похоже.
Таймеров понавставлял :)

Завтра потестирую на выделенном сервере в датацентре ртс, вот это уже интереснее.
Спасибо:

Mikhail Sukhov

Фотография
Автор статей Программист Трейдер
Дата: 27.09.2011
Ответить


Alexander Перейти
Завтра потестирую на выделенном сервере в датацентре ртс, вот это уже интереснее.


Если будет готовая прога, я бы на своем логине прогнал. Главное, не в рынок заявки ставить.
Спасибо:
< 1 2 

Добавить файлы через драг-н-дроп, , или вставить из буфера обмена.

loading
clippy