Блог им. Prophetic

Предновогоднее обновление QuikSharp

Хочу поделиться новостью о предновогоднем обновлении библиотеки QuikSharp.

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

Берем тут: https://github.com/finsight/QuikSharp

QuikSharp — это динамически подключаемая библиотека, для обеспечения связи ваших роботов, написанных на C#, с терминалом Quik.

QuikSharp — это «Open source-проект», который развивается благодаря участию других пользователей. Отдельный «респект» хочу выразить автору проекта, т.к. это именно то, что я долго искал когда понял, что уперся в некоторые существенные ограничения QLua.
Легче всего с этой библиотекой будет освоиться тем, что уже пробовал реализовать свои торговые стратегии на QLua, т.к. большинство функций взяты именно из QLua. Но по сравнению с QLua, мы получаем значительно большие возможности, в том числе по производительности. Когда у меня количество одновременно запущенных роботов на QLua превысило десяток, то я столкнулся с очень большими проблемами производительности. Квик стал жрать память в каких-то неимоверных объемах, а загрузка ЦП выросла до 80% (в спокойное время). Перейдя на QuikSharp (правда, перед этим пришлось заняться изучением C#) я одномоментно решил большинство проблем производительности, получил удобный инструмент для создания пользовательских интерфейсов, а также более удобное средство разработки самих роботов. Сейчас у меня одновременно крутятся в реальном времени более 4-х десятков роботов (если считать отдельным роботом сочетание ТС и конкретного инструмента), и при этом я не испытываю НИКАКИХ проблем с производительностью (терминал и роботы крутятся на ноутбуке).

Чтобы начать пользоваться данной библиотекой, необходимо скачать проект по указанной ранее ссылке и скомпилировать его (рекомендую использовать Visual Studio не ниже 2015).
После этого, из папки «bin» необходимо скопировать папку «lua» со всем ее содержимым, туда, где у вас обычно лежат роботы на QLua.
В терминале Квик в диалоговом окне «Lua скрипты...», необходимо добавить файл QuikSharp.lua из ранее скопированной папки «lua» и запустить этот скрипт.
Возможно, потребуется сначала установить LuaForWindows.
Далее, в папке «Examples\QuikSharpDemo\bin\Release» находим exe`шник, и запускаем его. Остальное должно быть понятно интуитивно.
Данная демка не является роботом, а лишь демонстрирует простейшие примеры работы с библиотекой, что в сочетании с открытостью исходников, позволяет без особого труда научиться использовать эту библиотеку в своих целях.
Возможно, позже будет реализован и какой-нибудь простейший робот, в качестве наглядного примера (может я сделаю, а может кто-нибудь еще)
★25
94 комментария
Вы наступили на горло Осе. Так держать. Конкуренция это хорошо. 
avatar
Евгений, Я не мог никому на горло наступить. Я НЕ являюсь автором проекта, лишь вношу посильный вклад в его развитие. К тому же, я не уверен, что эта самая «Ося» появилась раньше QuikSharp. Сам я пользуюсь данной библиотекой уже больше года, а вообще проект существует с конца 2013 года, просто раньше я на него не натыкался.
avatar
Евгений, Подобные проекты погибают смертью храбрых, поскольку есть LUA. С его выходом кофите, сток шарп, осы и подобное суть бестолковая вещь
avatar
kbrobot.ru, бестолковая вещь — это вы. Потому что кбробот шарлатан и обманщик.
avatar
Оса появилась неделю назад.

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

Оса сырая и непонятная. Может ваш проект (проект, в который вы вносите посильный вклад) подстегнет коллег сделать человеческое.
avatar
Евгений, На счет «подстегнет» у меня есть большие сомнения. Когда я впервые столкнулся с необходимостью вывода логики роботов за пределы процесса Квика, то первое с чем я столкнулся, это или «закрытые» проекты коннекторов к квику, работающие только с теми программами, которые являются коммерческими проектами, либо это различные варианты работы через DDE, которые требуют обязательной настройки определенных таблиц внутри квика. На QS я наткнулся совершенно случайно, когда уже практически опустил руки и думал, что придется продолжать сидеть на QLua.
avatar
Prophetic, а вы смотрели в сторону транзака или плазы? Там так же Си. Попробуйте, может это лучше будет для вас, чем доделывать проект чужой.
avatar
Евгений, Смотрел, но как раз в промежутке между расстройством от того, что не нашел ничего подходящего, до натыкания на QS. Когда разобрался с QS, остальные варианты отпали. Попробую пояснить свою позицию:
— мне нужен инструмент технического анализа, работающий в рилтайме. Так я нахожу свои стратегии.
— Мне НЕ нужна сверх-высокая скорость отклика, т.к. на фондовой секции у меня работают краткосрочно-среднесрочные системы, а на срочке — краткосрочные спекуляции (в среднем пара дней в позиции), для которых закладываемого проскальзывания в 5 пунктов пока хватает «за глаза».
— Мне нежелательно лишнее увеличение «костов» на содержание инфраструктуры (квик мне обходится бесплатно)
— Я НЕ являюсь профессиональным программистом
— До QS я писал роботов на QPile, а потом на QLua. Соответственно, после QLua, переход на C#, с использованием QS, практически не составил больших сложностей (не считая необходимости пройти курс обучения языку, который я тупо нашел в Ютубе)
— Я получил в свое распоряжение, совершенно бесплатно, удобную для меня библиотеку-коннектор. Отплатить автору той же монетой для меня не проблема. А если этот проект поддержат больше пользователей, то возможно я еще и что-то полезное для себя приобрету (имеются в виду знания)

Сопоставив описанные выше факторы, для меня выбор был очевиден.
avatar
Prophetic, как на ваш взгляд проекты Тс лаб, стокшарп, питон? Чем они могут не подходить в торговле?
avatar
Евгений, Питон — не пробовал. Остальные пытался смотреть, но меня они интересовали только как средства разработки и тестирования ТС, а без подключения к серверам (терминалам/брокерам) они у меня работать не захотели. После этого я на них забил. А вообще, я считаю, что средства разработки и тестирования должны быть сами по себе, а «боевой» робот сам по себе. Попытка создать All-in-One ни к чему хорошему не приводит в большинстве случаев.
avatar
Prophetic, если робота отдельно, то стокшарп или питон. Тс лабе все внутри, что плохо, соглашусь. Тыкание в кубики влияет на живую торговлю.
avatar
Евгений, Сток шарп — это «закрытый» проект, да еще и платный (в нормальном функционале), если я правильно помню. Питон — это еще один язык программирования к изучению, к тому же не на столько популярный как C#. Возникает закономерный вопрос: А зачем оно мне надо?
avatar
Prophetic, стокшарп позиционирует себя как бесплатный проект. Там есть платные вещи как Плаза, но с Квиком он бесплатен. С другой стороны, вам самому Плаза не интересна. Лично мне от стокшарп интересен только тестер.

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

Что касается классификации (программист или трейдер), то мне трудно ответить однозначно. С одной стороны — те QPile, QLua, C# я изучал только ради того, чтобы роботизировать торговлю, т.к. не имею возможности постоянно сидеть за терминалом (иногда, терминал вижу 2-3 раза в день, где 1 раз — это утренний процесс запуска).
С другой стороны, жизнь так сложилась, что я всюду старался автоматизировать различные нудные повторяющиеся процессы (в училище, в армии, на работе), чтобы высвободить свое время. Как следствие — пришлось изучать программирование, и сейчас этот процесс мне тоже нравится в некоторой степени.
Пока писал, пришел к такому выводу: В моем случае можно сказать, что эффективный трейдинг без программирования невозможен. Взять тот же анализ сделок: Мои кучки роботов генерируют массу логов, и для того, чтобы с ними было удобно работать, мне пришлось написать собственную «читалку логов», с механизмом анализа стратегий.
avatar
Prophetic, любую стратегию, запущенную на живых деньгах, можно протестировать. Ваш же мозг позволяет их закодировать. Позволит и протестировать.

Мое мнение, вы сильно обеспокоены экзекьюшеном и кодированием, чем поиском альфы. И это плохо. Но это ваше решение, и к чему оно приведет будет известно только вам.
avatar
Евгений, Все может быть. Время покажет…
avatar
Евгений, серьезно!? Питон!? :) Это же дико медленная штука, которую можно наверное эффективно использовать для бэктеста с момощью Pandas/NumPy/etc (batch processing), но можно даже не надеятся создать систему в реальном времени, где будет крутиться много стратегий (GIL, дико неудобная concurrency story по сравнению с .NET). Придется переписывать код для запуска в продакшн.
avatar
buybackoff, вы наивно полагаете, что Lua Quik и еще с десяток прокладок от брокера будет быстрым решением.

Быстрые решения делаются совершенно не так.
avatar
Евгений, расскажите же как! Я очень НЕ наивно написал здесь несколько раз обратное про QS, но вы наверное не читали.
avatar
Евгений, для «тыкания кубиков» делается копия скрипта. Например, в торговле версия 5, а модификация идет в версии 7.
avatar
ch5oh, сам подход достаточно пагубный. Роботы должны быть отдельно (причем без всякой шелухи, только прямое подключение к брокеру), а тестирование отдельно в программе.
avatar
Lua — это маленький и элегантный язык… Для тех, кто уже знает какой-либо язык изучить Lua -дело нескольких дней… Мне, например, lua сильно понравился..., но писать на чистом lua большие проекты не есть комильфо… Кстати луа, даже его автором позиционируется как «клей» — промежуточный слой, который помогает связывать некую систему с более мощным языком…
Сергей Гаврилов, а у Lua же наверное есть сетевая библиотека? Тогда сам скрипт может просто общаться с бэк-эндом через сокет, отправляя данные и получая инструкции, какие ордера выставлять-снимать и статус. А сам бэк-энд пиши на чём хочешь. У меня так робот в MT5 работает, сам советник чисто как прокся.
Zweroboi, Этот проект так и сделан.
avatar
ch5oh, тогда категорически поддерживаю )

Луа сам по себе легкое порно, а "Луа внутри Квик" — уже хардкор.


Авторам библиотеки QuikSharp хотелось бы пожелать больше тестировать её на нормальных боевых задачах.При нормальном потоке тиковых данных.

avatar
ch5oh, Лично я с тиковыми данными не работаю, поэтому мне трудно осуществить объективную оценку. Но автор библиотеки, на сколько я помню, делал какие-то тесты производительности, и вроде как результат был весьма неплохой, но это лучше у него и спросить. Ну и конечно же, ничто не мешает Вам провести собственное тестирование производительности для тех задач, которые Вас интересуют.
avatar

Prophetic, =) разумеется, я это проделал. И тесты производительности и всё прочее. Очень сыро. Видно, что именно на серьёзных промышленных задачах эту либу мало используют.

 

И ещё Вы путаете "производительность отдельной операции в одном синтетическом тесте" и "общую стабильность связки под нагрузкой".

avatar
ch5oh, Ну, мне кажется, что для промышленных задач используются результаты труда высокооплачиваемых программистов. Да и всякие квики в качестве прослойки для таких задач тоже не используют. Как я уже написал, про производительность ничего путного сказать не смогу. И моих знаний будет явно недостаточно, чтобы что-то улучшить в этом плане, а что касается «сырости» в остальном, то тут я бы попробовал с Вами поспорить. На начальном этапе, мне действительно не хватало многого в этой библиотеке, но сейчас (в том числе с моими доработками), нехватки функционала или нестабильности (напомню, что у меня одновременно несколько десятков роботов крутятся через один терминал) я не ощущаю. Может напишите, что кроме производительности Вас не устраивает в этой библиотеке? Может оно и мне надо…
avatar
ch5oh, какие результаты тестов? можно подробнее? годится таки или нет?
avatar
ch5oh, это глупо даже пытаться претендовать, что для тиков и HFT стоит использовать QS. Хотя, даже по Ри/Си тиков не так много по сравнению с заявками, миллион за 8 часов — это всего 34 в секунду. Главный вопрос латентности — от QS до квика это всего 60 микросекунда, но от Квика до сервера брокера и от него до биржи — сотни миллисекунд. Если нужны тики, то Plaza/Twime/Fix, QuikSharp же создавался как самый простой интерфейс поверх Луа, там специально нет и не будет какого-то дополнительного функционала, как тестирование стратегий и т.п. Но то, что есть — просто, открыто, быстро и удобно!
avatar
buybackoff, Ведь тики это стандартный функионал Квика, почему же нельзя на них претендовать? На ХФТ через квик я думаю никто и не претендует, для этого действительно есть Плаза и тд, речь про стабильность работы под нагрузкой... 60 микросекунд это скорость при пустом сообщении, но чем больше данных мы вкладываем в передаваемое сообщение тем медленнее оно работает.
avatar
PavelS, я уверен, что QS сам по себе не добавляет серьезной нагрузки, а сериализация и сокеты — как есть, это не мой код, а встроенный стек и JSON.NET. Быстрее уже не получится, если приходится работать с JSON и гонять данные через прослойку Луа. У меня Квик сам по себе обычно жрет много ресурсов, когда открыта таблица всех сделок и много стаканов. С тиками QS легко справится, только зачем это нужно, если реагировать на них можно с задержкой почти полсекунды!? Можно извращаться и использовать LuaJit, Jil вместо JSON.NET, thread-safe cjson всместо dkjson. Но все это упрется в медленность Квика и цепочки до биржи через брокера. Цель QS — дзен простота для быстрого прототипирования и работы со стратегиями, для которых секуда задержки не важна. Не получится сделать быстрее, чем Луа, если эта прослойка присутствует, и я не уверен, что те стратегии, о которых Вы пишете, работают супер быстро в Луа. Кстати, QS удобен и в связке с Plaza, так как позволяет получить данные об инструментах, состоянии счета и т.д., многих таких данных нет в основном потоке Плазы. А для рынка акций мега скорость не так важна, даже по Сберу не так много сделок.
avatar
buybackoff, Про медленность квика и цепочки до биржи через брокера речь не идет, тут все понятно. Про какие либо стратегии тоже речи нет. Как раз проблема (не постоянная, но достаточно частая) в том что я фиксирую время когда луа дал ответ и когда этот ответ пришел в робота, и так как приходится иногда одновременно работать с десятками заявок, то бывает такое: Отправка заявки и выполнение ее квиком 0.2 млс, получение колбека OnTransReply на прослойке Луа и отправка в квикшарп 64 млс, а получение квикшарпом 800 млс.

В Plaza2 CGate все эти данные есть.
avatar
PavelS, если там идет большой поток, то все сообщения выстраиваются в очередь, может поэтому. Вообще 800 млс я бы рассматривал как баг, интересно подробнее узнать про ситацию. Может быть это stop-the-world GC, по умолчанию GC на десктопе не в concurrent режиме. Как минимум нужно добавить array pool для JSON.NET, эта возможность появилась в 9-й версии, а также изменить настройки GC на server concurrent.
avatar
buybackoff, В дополнение вот например куск моего лога с нагрузкой.
(в скобках это время ответа луа, до скобок время получения этого ответа в C#)



avatar
PavelS, насколько часто повторяются такие паузы? Это похоже на GC, на Ваш взгляд?
avatar
buybackoff, Видите как прыгает время ответа, большую часть времени цифры до скобок и в них либо одинаковые либо отличаются на 1 млс. Таких ситуаций процентов 5-10.
Похоже или нет к сожалению не знаю, не могу понять где это происходит. Но идею Вы дали, буду пробовать, разбираться. Но врятли сделаю это быстрее Вас.
avatar
PavelS, в идеале бы запустить perfview при реальной нагрузке и посмотреть статистику github.com/Microsoft/perfview
avatar
PavelS, я внес изменения, которые должны существенно снизить GC. Не тестировал и в ближайшее время не смогу. Попробуйте обновить и проверить есть ли еще длинные паузы.
avatar
buybackoff, Запустил, пока все работает нормально, посмотрим.
avatar
PavelS, скажите, есть ли в итоге заметное улучшение после изменений?
avatar
buybackoff, Да, стало лучше, правда я снизил нагрузку, сейчас запущено мало роботов. Но все равно подобные ситуации повторяются. Один раз было прямо очень плохо, задержки дошли до 50 секунд, но наверное это не в библиотеке, не знаю, перезапуск все вылечил, больше такого не повторялось. 
avatar

PavelS, 50 секунд даже Питон наверное висеть не будет, вероятно дело не (только) в GC — так долго мусор не может собираться при любом раскладе. Учитывая, что вся библиотека — это по сути TCP сокет + (де)сериализация, не могу с ходу придумать где я что-то еще мог пропустить. Рад слышать, что стало лучше — надеюсь Вам не показалось :)

Пишите, пожалуйста, на ГитХаб все такие проблемы, если они будут повторятся — мы их поправим!

avatar
PavelS, добавил issue, если есть возможность, опишите подробнее где именно сообщение зависает на так долго
github.com/finsight/QuikSharp/issues/89#issue-197999438
avatar
buybackoff, Это не только транзакции, но и OnOrder. В OnTrade не знаю, его не замеряю.
avatar
buybackoff, Добрый день! Вернулся к вопросу подвисания потоков...
Подвисает все в QuikService, поток callbackTask. А конкретно вот тут: var lineOrCancelledTask = await Task.WhenAny(readLineTask, _cancelledTcs.Task).ConfigureAwait(false);
Подвисает не постоянно в среднем на 2-5 секунд, но может доходить до нескольких минут.
Подскажите почему такое может происходить, как можно это исправить?
avatar
PavelS, видимо он ждет ответа от readLineTask, который читает колбэки с сокета. Если посмотрите выше, то там идет напрямую вызов StreamReader(NetworkStream()).ReadLineAsync(), что является кодом .NET. То есть проблема может быть только в том, что пакеты не приходят, что в свою очередь может быть вызвано неполадками на стороне Квика. В коде QuikService я не вижу возможных проблем в этом случае.

Было бы неплохо сделать логирование на стороне Lua и в этом месте и посмотреть, где именно зависает. То есть если Lua скрипт вызывает нужный метод вовремя, то нужно разбираться в сокетах. Иначе проблема может быть в самом Квике или к коде Луа. Скажите, пакеты все в итоге приходят или некоторые теряются?
avatar
buybackoff, Бывает что позиции резко разошлись с квиком, как будто в какой то момент не пришли колбеки со сделками. 
Сильно подвисать начинает после одного-двух дней непрерывной работы, колбеки начинают тормозить на 2-5 минут каждый, тоесть если это началось, то так и будет работать пока не перезагрузишь. При этом примерно в 7 раз возрастает объем используемой опер.памяти и нагрузка на ЦП.  Квик при этом часто тоже подвисает.
avatar
PavelS, а какой процесс есть много памяти и если QUIK#, то не делали profiling? Несколько дней непрерывной работы — звучит амбициозно :) Когда еще руками использовал Квик перезагружал хотя бы раз в день… За несколько дней может накопиться много мусора в разных местах, я вообще ничего не могу сказать о такой ситуации удаленно. Есть такая удобная штука: https://github.com/Microsoft/perfview, она позволяет профилировать уже запущенный процесс (dotTrace/dotMemory тоже, но они платные; второенный в VS профайлер не позволяет присоединиться к запущенному процессу). Когда в следующий раз начнутся проблемы со скорость и памятью, можете запустить и посмотреть что съедает память?
avatar
buybackoff, Память начинает жрать сам робот, не quik. Profiling не делал. Когда все это происходит, то перезагружаю только робота, quik не трогаю, он месяцами работает без перезапуска. Если при появлении этих тормозов подвисал и quik, то при закрытии робота quik сразу восстанавливается.
avatar
PavelS, тогда точно профайлинг поможет. Я еще ни разу не делал полноценный нагрузочный тест и публично не раз тут писал, что Q# создан для удобства, а не для замены Плазы/FIX, поэтому я в свое время остановился на том, что он «вполне достаточно» быстр… Без профайлинга не понять в чем причина — в Q# или в коде робота.
avatar

PavelS, есть одна мысль — вы случайно не используете блокирующие методы слишком часто? (по сравнению с асинхронными). Есть такая тема как ThreadPool starvation: https://stackoverflow.com/questions/7600774/threadpool-not-starting-new-thread-instantly. Когда все потоки ThreadPool заняты, то пул ждет одну секунду перед тем, как добавить новый поток. Если у вас в коде много блокирующих методов, то потоки в пуле могут закончится и пул будет ждать секунду. При этом если есть очередь из тасков, то последний может ждать довольно долго.

Q# асинхронный, проверье не используете ли Вы везде Task.Result или Task.Wait() вместо await...

 

avatar
buybackoff, Resut использую только в запросах к квику, например: classCode = _quik.Class.GetSecurityClass(«SPBFUT», secCode).Result;

и таких запросов около 10 на весь код, 6 из них работают в цикле в отдельном потоке с паузой 10 мс (это загрузка параметров по инструментам и стаканов, а также графиков). 4 это отправка транзакций например res = _quik.Orders.CreateOrder(order_new).Result;

Больше нигде ничего не жду, кроме этих запросов.


avatar
PavelS, тогда надо думать. То, что Квик тормозит когда тормозит робот, но отвисает после перезапуска робота, может говорить о том, что Квик пихает в сокет данные, но буффер сокета переполнен по какой-то причине — читатель не успевает все считать. Попробуйте еще без WhenAny() если не используете CancellationToken, где-то недавно в issues CoreFx видел репорт о баге с утечкой памяти где-то там WhenAny/WhenAll.
avatar
buybackoff, Сейчас вообще убрал var lineOrCancelledTask = await Task.WhenAny(readLineTask, cancelledTcs.Task).ConfigureAwait(false);
if (lineOrCancelledTask == _cancelledTcs.Task) { break; }

Что делает этот код, зачем он нужен?
Второй день работаю без него, пока все нормально. Только начали наблюдаться задержки 2-10 сек в строке var readLineTask = reader.ReadLineAsync(); но не так часто.
avatar
PavelS, это поддержка отмены операции, так как асинхронные методы сокетов не поддерживают CancellationToken.
avatar
buybackoff, Подскажите, не могу понять для чего Вы делаете цикл в цикле (в потоках отправки, приема и колбек) например:




avatar
PavelS, внешний цикл — это реконнект. Мы в него выходим из внутреннего только после IOException.
avatar
А что нового в библиотеке? Просто дописали реализацию недостающих функций из QLua?
avatar
PavelS, Да, просто добавились новые функции (без некоторых из них я вообще не мог нормально робота построить), плюс добавился Демонстрационный проект, который наглядно демонстрирует пример создания приложения.
avatar
Prophetic, С графиками работаете? Как грузите?
avatar
PavelS, Не очень понятен вопрос. Работаю с числовыми значениями графиков (OHLCV). Визуализацию графиков не выполняю (для работы робота это не требуется, а для просмотра есть квик).
Гружу путем подписки на получение соответствующих таблиц из квика. Вообще-то, в демке это как раз есть. Для того ее и делал.
avatar
Prophetic, Сколько времени займет получение всего графика, например М1? В предыдущих версиях получение около 3000 свечей (примерно столько дает квик) занимало от 3 до 6 секунд (это очень долго). Причем в цепочке Сериализация-сокет-десериализация-луа-сериализация-сокет-десериализация обработка команды самим ЛУА и выдача им результата занимает 0,5 милисекунды. Вот в этом проблема. Библиотека не справляется с потоком больших пакетов. Может уже исправлено? Кстати в ваших примерах ошибки, чтобы скомпилировать пришлось дорабатывать.
avatar
Prophetic, Я давно пользуюсь этой библиотекой, правда от нее осталась только идея, все остальное переписано, добавлена логика работы с плазой и метатрейдером, но проблема с большим потоком данных при работе с квиком все равно осталась. У меня крутится около ста роботов и у каждого в управлении по 4 заявки и если ко всему этому добавить например колбеки стакана и обезличенных сделок, то начинаются большие задержки, периодически получить транзакцию занимает несколько секунд.
avatar
PavelS, пулл реквесты принимаются, всегда можно исправить что вас не устраивает. Большие потоки данных и Квик как-то плохо сочетаются в принципе… Библиотека сосдавалась в первую очередь для простоты, хотя по скорости она оптимальна в текущей архитектуре и отпрофилирована.
avatar
Prophetic, Получение различных параметров пришлось объединить в небольшие пакеты, получилось на 2 милисекунды быстрее чнм все их получать по отдельности, как это делаете Вы.
avatar
PavelS, Попробую по порядку:
1. Не засекал. И для меня это момент не критичен, т.к. мне не приходится постоянно выполнять данную операцию. В своих системах для пакета роботов, первичные таблицы свечей робот получает на старте приложения (с учетом обработки почти трех десятков бумаг, этот процесс действительно занимает приличное количество времени — где-то около минуты). Но далее все полученные таблицы записываются в объединенное хранилище, и каждая стратегия не получает данные заново, а просто берет их из хранилища. Обновление таблиц происходит по колбэкам, путем добавления новой свечи в конец соответствующей таблицы. Т.к. я все же не являюсь автором проекта, то даже не задумывался над анализом проблем обработки больших пакетов данных (у меня банально знаний не хватит)
2. Ошибок быть не должно, перед тем как отправить PR я ВСЕГДА компилирую проект и запускаю свои «боевые» приложения на свежей версии библиотеки. То же самое касается демки. Может напишите в каком месте у Вас ошибка вылезла (ведь вряд ли ошибка возникла после слияния)?
3. Собственно и свечки и таблицы заявок и таблицы сделок у меня хранятся в отдельных хранилищах, асинхронно обновляющихся по колбэкам. Если же вы пытаетесь найти плохую оптимизацию в демо-приложении, то это занятие бесполезное. Вполне очевидно, что оно не образец для подражания, и было создано только потому, что многие пользователи, которые пытались познакомиться с библиотекой, просили реальные примеры работы.
У меня все реализовано сильно иначе. Если грубо, то: Есть оболочка, содержащая в себе хранилище, и основные управляющие функции. Есть кучка различных торговых стратегий, каждая из которых упакована в отдельную DLL. Конкретный робот представляет из себя сочетание выбранной ТС из доступных в папке и тикера инструмента. Соответственно, у каждого такого сочетания свои файлы настроек параметров робота.
avatar
Prophetic, 1. Это понятно что полная загрузка происходит один раз, у меня так же. Если для Вас скорость работы не критична это не значит что и всем тоже, надо развивать проект...
2. Пишу с телефона, поэтому не могу точно указать на ошибку. Но если примерно то Вы пытаетесь получить некоторые поля таблици, которые не описаны в библиотеке квикшарп. И еще так как нет скомпилированной библиотеке квик шарп, то слетают ссылки в Вашем демо, пришлось собирать библиотеку, и заново указывать ссылки
avatar
PavelS, 
1. «Вы пытаетесь получить некоторые поля таблици, которые не описаны в библиотеке квикшарп». Если читать это «в лоб», то у меня проект просто не работал бы, а это не так (сейчас попробую скачать прямо по той ссылке проект в отдельную папку и еще раз попробовать скомпилировать). Единственное, что приходит в голову, это то, что я не стал преобразовывать форматы даты, при выводе таблиц. Но это я видел, и просто в соответствующей колонке таблицы, вместо нужного значения выводится всякая белиберда, что не мешает работе демонстрационного приложения (мы ведь не обрабатываем нигде эти даты потом).
2. На счет ссылок — надо подумать. Понятно, что я много раз компилировал библиотеку и лишь потом подключил демку к решению. Возможно, достаточно просто провести повторную компиляцию, без внесения изменений, но это надо проверять. Или надо искать какой-то другой способ указания ссылок, но тут у меня знаний может и не хватить.
avatar
PavelS, Проверил дистрибутив из репозитория. Вы правы Была небольшая ошибка (почему-то не отловил после рефакторинга класса).
Строка: firmID = quik.Class.GetClassInfo(classCode).Result.firmid;
Должна была быть написана так: firmID = quik.Class.GetClassInfo(classCode).Result.FirmId;

Ошибку исправил и перезалил в репозиторий. Спасибо, что заметили.

И кстати: с сылками каких-либо проблем не возникло. Поэтому, тут я даже не представляю где искать возникшую у Вас проблему.
avatar
Prophetic, У меня Ваш Демо зависает на этапе подключения.
avatar
PavelS, Проверил. Буквально только что скачал последнюю версию проекта из репозитория (для чистоты эксперимента) в отдельную папку. Скомпилировал проект (все прошло без ошибок), взял из папки "\QuikSharp-master\Examples\QuikSharpDemo\bin\Release" экзешник и запустил (Lua-скрипты у меня загружены давно а работают постоянно). Все прекрасно работает.



avatar
Prophetic, Попробуйте перезапустить Lua-скрипт в терминале, и убедитесь, что кроме этой демки больше никакое приложение, с использованием этой библиотеки, не подключается к терминалу.
avatar
Prophetic, У меня к сожалению тоже не хватает знаний что бы докапаться до проблемы. Уже давно с ней мучаюсь, так как для меня скорость обмена данными очень важна. Например грузим в отдельном потоке параметры инструментов. 50 инструментов по 20 параметров, на каждый запрос уходит около 0.5 млс итого 500 млс, а квик обновляет данные с интервалом 30 млс и пока мы грузим один раз все инструменты параметры могут уже несколько раз поменяться
avatar
PavelS, Могу ошибаться, но правильно ли я понимаю, что Вы грузите ВСЕ параметры, для каждого инструмента, да еще и по колбэку OnParam? Если я прав, то склонен согласиться с тем, что возможны проблемы с производительностью, т.к. объем данных там получается огромный. Я в свое время отказался от такого подхода, т.к. понимал, что 90% полей параметров инструмента мне вообще не нужны, и нагружать систему их пересылкой нет никакого смысла. Еще  9% мне нужны с периодичностью не чаще 1-го раза в час, и около 1% мне действительно приходится запрашивать практически в каждом цикле. Как результат — нужные мне параметры я получаю через GetParamEx. А объем передаваемых данных получается в десятки раз меньше. Вот и нет у меня проблем с производительностью. :)
avatar
Prophetic, Нет, я не гружу все параметры, только необходимые мне.
OnParam не пользуюсь, не получается сделать это без проблем, с этим колбеком приходит код и клас инструмента по которому были изменения, что Вы с ними делаете дальше? Если я обращаюсь обратно к квику за параметрами по данный бумаге (из этого же потока или из другого, не важно), то очень скоро поток который обращается к квику зависнет.
avatar
PavelS, Ну, в силу ряда обстоятельств мне пришлось отказаться от использования этого колбэка. Но когда использовал, то по нему у меня запускался цикл обработки логики робота, а необходимые параметры запрашивались уже внутри этого цикла. Вообще, из-за того, что у меня время расчета одного цикла может достигать 17ms (если верить студии), а колбэки в активный период приходят значительно чаще, я бы сейчас использовал флаг игнорирования приходящих колбэков OnParam. Т.е. при получении колбэка- устанавливаем этот флаг и запускаем цикл. К конце цикла снимаем флаг.
avatar
 Да, что нового добавили?
avatar
ch5oh, 
Add classes: Param, QuikTable
Add callbacks: OnStopOrder, OnParam

Add functions (metods):
GetSecurityClass
GetClientCode
GetTradeAccount
GetOrders (+ 1 перегрузка)
GetOrder_by_transID
GetOrder_by_Number
GetDepoEx
GetTrades
GetTrades_by_OrderNumber<br><br>Плюс демо-приложение. Ну и по мелочи код немного "причесали".<br>
avatar
Prophetic, А Вы выставляете заявки и контролируете их выставление так же как в Демо примере?
avatar
PavelS, Не совсем. структура моих реальных роботов значительно сложнее, и включает в себя различные методы контроля сбоев, плюс учитываются еще ряд факторов.
Если обобщенно и упрощенно, то как я писал ранее, у меня в хранилище есть таблица заявок. Если робот выдал сигнал на выставление заявки, то отдельно фиксируется номер этой заявки, и далее в каждом цикле проверяется состояние этой заявки. Если заявка в результате была отменена (я задаю время ее жизни), забываем про заявку и работаем «с нуля». Если заявка перестала быть активной и остаток к исполнению не равен стартовому количеству в заявке, то лезем в таблицу сделок (которая также хранится в хранилище), и по номеру заявки находим все сделки. Далее высчитываем среднюю цену и продолжаем обработку согласно логике робота.
avatar
Prophetic, Тоесть колбеками  OnTransReply, OnOrder и OnTrade не пользуетесь, а все время проверяете в цикле через запросы в квик?
avatar
PavelS, В целом — «Да», но OnOrder и OnTrade используются для обновления таблиц в хранилище.
avatar
Пример зависает на Подключаемся к терминалу Quik...
запущен или нет QuikSharp.lua  значения не имеет.
Чтото-не так с дллками, трудно понять.
Может подскажете, что где проверить?
Спасибо.
avatar
pantov, Если у Вас к библиотеке квикшарп подключена Newtonsoft.Json версии 9.01, то скорее всего из за нее, откатите на 8.03. У квик шарпа есть проблемы с более новыми версиями Json. Еще есть проблемы с колбеками, в частности с Events.OnConnectedToQuikCall(_responsePort) в QuikService.cs, из за него падает поток.

Еще есть проблемы с сепаратором в Demo. 
avatar
PavelS, Json у меня например стоит 9.0.0.0. Проблем не было.
по поводу «Events.OnConnectedToQuikCall(_responsePort)» — что-то странное. вроде больше ни у кого проблем в этом месте нет, но вероятно лучше задать вопрос тут: https://github.com/finsight/QuikSharp/issues
А что за проблемы с сепаратором у Вас возникли?

avatar
Prophetic, Ну у меня так получается. Если взять Ваш проект по ссылке, то со свежим Json он выдает исключение, откатываю на 8.03, данная проблема исчезает.
По колбеку ошибка не постоянная, но ловил ее уже несколько раз.

А по сепаратору, Вы насильно даете ему "," а если у кого нибудь в региональных стандартах разделитель стоит "." то будет исключение. 
Поэтому если уж так нужно менять разделитель то лучше заменить System.Globalization.CultureInfo.CurrentCulture.NumberFormat.CurrencyDecimalSeparator[0];

на System.Globalization.CultureInfo.CurrentCulture.NumberFormat.NumberDecimalSeparator[0]; тогда он берет его из локальных региональных настроек

avatar
PavelS, Спасибо, проверю. Мне казалось, что используемая мной запись как раз и должна брать разделитель из текущих локальных настроек системы. Видимо сказывается недостаток знаний.
avatar
Prophetic, на русской версии виндовс Ваша команда берет то что принято стандартом для России, а у нас это ","
Это я опытным путем вычислил)) у меня виндовс с русской локализацией а разделитель стоит точка и эта команда выдает все равно запятую.
avatar
PavelS, Понятно. Повнимательней изучив строку, я также обратил внимание, что использовал разделитель для денежных единиц, что в ряде случаев также могло создавать дополнительные сложности. Ошибку учел. Спасибо. В репозиторий наверное попозже буду выгружать, когда еще что-нибудь добавится.
avatar
PavelS, создайте плиз Issue на ГХ, если проблема повторяется.
avatar

теги блога Prophetic

....все тэги



UPDONW
Новый дизайн