Alexander
|
Date: 9/27/2011
FiNick:
Кстати, странная фишка: у меня если плаза не подключена проц на 100% забит, подключаю нагрузка до 0-2% падает, отключаю опять 100%.
Исправил, фикс - в исходниках codeplex [cool]
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
Произвёл замеры на тестовом сервере биржи - 100 заявок.
- регистрирую время - посылаю заявку
- получаю ответ от биржи - регистрирую время.
В итоге средняя разница между 2) и 1) составила 140мс (это не с сервера биржи, а с рабочего компа).
Максимальное время - 2148мс, минимальное - 58мс.
Такой всплеск - до 2 секунд был 1 раз, в остальном заявки - до 150мс, пару раз было по 500мс. Первая посланная заявка - 600мс.
Пошёл дальше - посмотрел на среднюю задержку пакетов от меня до биржи - с помощью rts echo. В итоге после 50 тысяч запросов - 105мс средняя задержка канала.
Всё, с тормозами Plaza2, похоже, решено.
Пользуйтесь.
Единственная оставшаяся задача - поддержка 64 бит. Желающих как обычно нет? :)
|
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
Отправил ещё 400 заявок.
Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды
минимальное - от 31 до 93мс.
|
|
|
|
Thanks:
|
|
|
|
|
|
Mikhail Sukhov
|
Date: 9/27/2011
Alexander:
Отправил ещё 400 заявок.
Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды
минимальное - от 31 до 93мс.
Можешь тесты залить так же на КодеПлекс? Даже лучше в качестве примеров. Чтобы в любой момент каждый смог бы проверить свою скорость под нагрузкой.
|
|
|
|
Thanks:
|
|
|
|
|
|
FiNick
|
Date: 9/27/2011
|
|
|
|
|
На форуме rts было написано:
Из этого следует несколько выводов:
а. Выбор синхронного или асинхронного способа отправки одинаков с точки зрения как скорости отправки, так и ожидания ответа и должен диктоваться внутренней архитектурой приложения.
Асинхронную отправку имеет смысл использовать, если
-- приложение однопоточное и получает реплику в том же Connection, который используется для отправки заявок. В этом случае сихронный Send будет блокировать получение реплики до момента получения ответа на сообщение.
-- приложение отправляет сообщения, не дожидаясь ответа на предыдущие отправленные сообщения
(например, классическая система интернет-трейдинга)
б. Обработка таймаута при ожидании на объекте ядра точно также как при Sleep квантуется по 10-15 мс.
Таймаут в 1 мс статистически эквивалентен таймауту в 10 мс. Так устроена ОС Windows.
в. уменьшать таймаут имеет смысл только для более частного возврата к коду пользователя, в случае, если ожидается, что данное соединение редко используется.
г. Таймаут = 0 в ProcessMessage означает, что один из процессоров или
процессорных ядер будет постоянно загружен обработкой пустого (по большей части) цикла данного потока.
У нас:
1мс AddTransaction
4мс SendAsync
33мс SendAsync
100мс SendAsync
Чем занимается SendAsync столько времени, оно же вроде асинхронная отправка, неужели дожидается какого-то ответа? И плюс почему PollTimeOut влияет на это время, судя по коду там есть TransactionTimeOut для этого (5 сек по умолчанию).
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
|
|
|
|
|
На форуме 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 - всё стало мгновенно.
Потестируйте у себя, интересно сравнить.
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
Mikhail Sukhov:
Alexander:
Отправил ещё 400 заявок.
Среднее колеблется в районе 120-140.
Максимальное (делаю пачками по 100 заявок) - от 400мс до 2.3 секунды
минимальное - от 31 до 93мс.
Можешь тесты залить так же на КодеПлекс? Даже лучше в качестве примеров. Чтобы в любой момент каждый смог бы проверить свою скорость под нагрузкой.
Они сейчас просто в виде подсчёта разницы DateTime внутри PlazaTrader. Попробую на выходных отрефакторить и выложить, хотя бы в виде диффа.
|
|
|
|
Thanks:
|
|
|
|
|
|
FiNick
|
Date: 9/27/2011
Alexander:
Потестируйте у себя, интересно сравнить.
До включения UseLocalProtocol: RegisterOrder работает в среднем 31 мс (кста, видно что там квант времени 15,625 мс, потому надо пользоваться каким-нибудь Stopwatch и т.п.), latency в среднем 180-200мс
После включения: RegisterOrder работает за 0мс (кроме первого раза), latency в среднем 150-170мс, т.е на эти 30мс меньше стала.
|
|
|
|
Thanks:
|
|
|
|
|
|
Alexander
|
Date: 9/27/2011
FiNick:
Alexander:
Потестируйте у себя, интересно сравнить.
До включения UseLocalProtocol: RegisterOrder работает в среднем 31 мс (кста, видно что там квант времени 15,625 мс, потому надо пользоваться каким-нибудь Stopwatch и т.п.), latency в среднем 180-200мс
После включения: RegisterOrder работает за 0мс (кроме первого раза), latency в среднем 150-170мс, т.е на эти 30мс меньше стала.
Latency как считаете?
|
|
|
|
Thanks:
|
|
|
|
|
|
Ortn
|
Date: 9/28/2011
|
|
|
|
|
Alexander:
Произвёл замеры на тестовом сервере биржи - 100 заявок.
- регистрирую время - посылаю заявку
- получаю ответ от биржи - регистрирую время.
В итоге средняя разница между 2) и 1) составила 140мс (это не с сервера биржи, а с рабочего компа).
Максимальное время - 2148мс, минимальное - 58мс.
Такой всплеск - до 2 секунд был 1 раз, в остальном заявки - до 150мс, пару раз было по 500мс. Первая посланная заявка - 600мс.
Пошёл дальше - посмотрел на среднюю задержку пакетов от меня до биржи - с помощью rts echo. В итоге после 50 тысяч запросов - 105мс средняя задержка канала.
Всё, с тормозами Plaza2, похоже, решено.
Пользуйтесь.
Единственная оставшаяся задача - поддержка 64 бит. Желающих как обычно нет? :)
Очень интересно какие результаты получатся у других людей. Сам проверить не могу т.к. нет доступа по плазе.
ЗЫ Не много не по теме, но может кто знает, насколько трудно получить тестовый доступ к серверу плазы? И можно ли это вообще сейчас сделать, или это только на время тестирования раздавали тестовые логины?
|
|
|
|
Thanks:
|
|
|
|
|