Тормоза на Плазе

Тормоза на Плазе
Atom
9/14/2011
FiNick


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

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


Tags:


Thanks:


<< < 2 3 4 5  >
Alexander

Avatar
Date: 9/27/2011
Reply


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


Исправил, фикс - в исходниках codeplex [cool]
Thanks:

Alexander

Avatar
Date: 9/27/2011
Reply


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

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

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


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


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

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

Alexander

Avatar
Date: 9/27/2011
Reply


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

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

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

Mikhail Sukhov

Avatar
Date: 9/27/2011
Reply


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

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

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


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

FiNick

Avatar
Date: 9/27/2011
Reply


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

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

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

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

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

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

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

У нас:
Quote:

1мс AddTransaction
4мс SendAsync

33мс SendAsync

100мс SendAsync


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

Alexander

Avatar
Date: 9/27/2011
Reply


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

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

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

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

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

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

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

У нас:
Quote:

1мс AddTransaction
4мс SendAsync

33мс SendAsync

100мс SendAsync


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


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

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

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

Alexander

Avatar
Date: 9/27/2011
Reply


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

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

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


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



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

FiNick

Avatar
Date: 9/27/2011
Reply


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

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

Alexander

Avatar
Date: 9/27/2011
Reply


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

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


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

Ortn

Avatar
Date: 9/28/2011
Reply


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

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

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


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


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

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


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

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

Attach files by dragging & dropping, , or pasting from the clipboard.

loading
clippy