четверг, 11 марта 2010 г.

Асинхронные заявки

Поделились со мною программой, которая четка показала - асинхронные заявки через Квик быстрее асихнронных заявок через .NET. Поясню, что значит последнее. Допустим, в программе необходимо заложить логику, которая бы мгновенно отправляла заявки на регистрацию, не дожидаясь подтверждения. Такое может потребоваться при написании привода, когда нужно максимально быстро послать запрос и возвратить пользователю управление (иначе GUI будет подтормаживать). Вот как это делается сейчас:
new Action(() => _trader.RegisterOrder(order)).BeginInvoke(null, null);

Довольно быстро. Но одному из пользователей S# потребовалась еще более быстрая скорость, и он попросил добавить поддержку асинхронных заявок в QuikTrader именно через механизм Quik API. Да не просто попросил, а аргументированно-программно доказал всю мою неправоту, прислав тестовую программу. Так как я раньше думал, что регистрация заявок через асинхронный механизм .NET имеет такую же скорость, что и через квиковский. Вот показатель разных способов:

1. Синхронный способ (QuikTrader.RegisterOrder) - 2-3 заявки в секунду.

2. Асинхронный способ .NET (Delegate.BeginInvoke) - 4-5 заявок в секунду.

3. Асинхронный способ Квик - 7-8 заявок в секунду.

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

9 комментариев:

  1. добрый день!
    правильно ли я понял, что:

    1. Синхронный способ(QuikTrader.RegisterOrder) - вызывает синхронный способ API квика QUIK_API.TRANS2QUIK_SEND_SYNC_TRANSACTION

    2. Асинхронный способ .NET (Delegate.BeginInvoke) - асинхронно вызывает Синхронный способ(QuikTrader.RegisterOrder)

    3. Асинхронный способ Квик -
    API квика QUIK_API.TRANS2QUIK_SEND_ASYNC_TRANSACTION
    ?????
    ----------------
    успехов!

    ОтветитьУдалить
  2. Добрый день!

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

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

    Ну и конечно было бы бесподобно видеть такую библиотеку в исходниках (но это скорее всего не входит в Ваши планы :( )

    ОтветитьУдалить
  3. Добрый день,

    "а в части внезапного изменения статуса проекта." - не понял, про что речь?

    ОтветитьУдалить
  4. про фриварность библиотеки

    ОтветитьУдалить
  5. artemox,

    Я не понимаю, о чем идет речь. Могли бы Вы привести ссылку на цитату, где упоминается S# и изменения статуса?

    ОтветитьУдалить
  6. sorry, может я не ясно изъяснился. Цитат таких я не видел, ровно как и обратных, как раз поэтому и спрашиваю, т.е. если Вы подтвердите, что в будущем библиотека НЕ станет платной, то этого будет вполне достаточно.

    ОтветитьУдалить
  7. Ок, теперь понял. Да, я неоднократно писал о том, что сам S# никогда не будет платным. У меня нет планов коммерциализации данного продукта. Возможно, в будущем я выпущу некие дополнительные сервисы, которые будут уже за деньги. Но, это точно будут как отдельные продукты, построенные, скорее всего, на базе S#.

    ОтветитьУдалить
  8. Спасибо. Удачи и сил в Вашем деле.

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