Как ускорить работу получения списка закрытых ордеров?
Добрый день, уважаемые программисты.
Столкнулся с такой задачей. Пишу советник, который должен частично закрывать сделку несколько раз при выполнении определенных условий. Для того, чтобы проверить, выполнены ли условия для следующего частичного закрытия, нужно для начала узнать, сколько раз от исходного ордера уже отщипывали кусочек лота. И это можно сделать только путем перебора всех закрытых ордеров и проверки времени открытия и направления сделки и цены открытия (все остальные параметры могут быть изменены советником, а комментарий меняется автоматически при частичном закрытии, поэтому его использовать его тоже не вариант). Вести журнал сделок с сохранением информации на жесткий диск не хочется (вряд ли выиграю по скорости - нужно файл открыть, прочитать, исправить, сохранить, закрыть).
При этом задача в том, чтобы советник был стабилен при сбое терминала, поэтому список закрытых ордеров получаю на каждом тике, но нужно решить вопрос быстродействия программы. Советник планируется запускать на нескольких парах одновременно и из-за мелкого таймфрейма список сделок быстро растет. Но из-за того, что эта же стратегия может применяться на старших таймфреймах, список отображаемой истории нужно держать хотя бы за месяц.
Так как проверку условий нужно совершать по каждому открытому на данный момент ордеру (а их может быть несколько), копирую информацию в память программы, записывая в структуру, чтобы потом осуществлять перебор в ней.
В принципе, чтобы не копировать весь список открытых ордеров (я фильтрую и собираю в массив структур только те ордеры, которые могут быть интересны самой программе в том или ином месте алгоритма), я думаю, что можно было бы узнать дату самого раннего открытого ордера из интересующих и не копировать историю младше конкретного числа. Но на практике этот подход может дать сбой, если пользователь в списке истории ордеров поставит сортировку, например, по валютной паре, объему или типу.
Больше не могу придумать никаких вариантов.
Может кто сталкивался с подобной задачей? Подскажите, как можно еще решить вопрос производительности?
Как раз по комментарию ордера частично закрытой позиции (mql4) вы можете отследить всю цепочку. В mql5 проще.
Я экспериментировал с этим - как раз по комментарию не получается, поскольку при частичном закрытии для нового ордера прописывается комментарий "from # ...", а у старого меняется комментарий на "to # ..." с тикетом нового ордера. При следующем частичном закрытии у закрытого ордера пропишется тикет нового (открытого на данный момент) ордера, а информация о предыдущем закрытии у него удалится. А перебирать по комментарию, от какого ордера образован текущий ордер (если он уже закрытый), равнозначно перебору по дате и цене. То есть схема с комментариями позволяет узнать только предыдущий тикет. А если откусываний несколько, то уже эта схема не работает.
если пользователь в списке истории ордеров поставит сортировку, например, по валютной паре, объему или типу - то он увидит историю в нужном ему виде. Но для программы история остается как на сервере - отсортированной по времени. Правда, гарантия этого отсутствует - брокер может произвести изменение их порядка, например, по жалобе. На практике за 7 лет такое отсутствовало. Попробуйте написать скрипт, выводящий номера (тикеты) последних например 15 ордеров. Произведите сортировку, например, по валютной паре, объему или типу и посмотрите результат.
Я экспериментировал с этим - как раз по комментарию не получается, поскольку при частичном закрытии для нового ордера прописывается комментарий "from # ...", а у старого меняется комментарий на "to # ..." с тикетом нового ордера. При следующем частичном закрытии у закрытого ордера пропишется тикет нового (открытого на данный момент) ордера, а информация о предыдущем закрытии у него удалится. А перебирать по комментарию, от какого ордера образован текущий ордер (если он уже закрытый), равнозначно перебору по дате и цене. То есть схема с комментариями позволяет узнать только предыдущий тикет. А если откусываний несколько, то уже эта схема не работает.
Может от брокера зависит, но на инсте у меня предлагаемый Вами способ не сработал.
Красными точками отметил один и тот же, несколько раз откусанный ордер (открыт 0,5, потом частично закрыл 0.10, потом - 0.05, потом 0.02) - как видите, везде в качестве комментария у меня тикет нового ордера (кроме последнего, окончательного закрытия этого ордера, закрытого оставшимся объемом 0,33).
И такая же штука со всеми остальными ордерами.
Наверное Вам не приходилось считать количество откусываний - когда открыт ордерр 376303649 (объемом 0,33), я по его комментарию могу узнать тикет 376300257. Но не глубже.
Может от брокера зависит, но на инсте у меня такой способ не сработал.
Красными точками отметил один и тот же, несколько раз откусанный ордер (открыт 0,5, потом частично закрыл 0.10, потом - 0.05, потом 0.02) - как видите, везде в качестве комментария у меня тикет нового ордера (кроме последнего, окончательного закрытия этого ордера, закрытого оставшимся объемом 0,33).
И такая же штука со всеми остальными ордерами.
У закрытого - тикет дочернего. У открытого - тикет родительского. Отсюда составляется полный список.
если пользователь в списке истории ордеров поставит сортировку, например, по валютной паре, объему или типу - то он увидит историю в нужном ему виде. Но для программы история остается как на сервере - отсортированной по времени. Правда, гарантия этого отсутствует - брокер может произвести изменение их порядка, например, по жалобе. На практике за 7 лет такое отсутствовало. Попробуйте написать скрипт, выводящий номера (тикеты) последних например 15 ордеров. Произведите сортировку, например, по валютной паре, объему или типу и посмотрите результат.
Благодарю. Действительно, список не меняется при изменении сортировки, проверил. Попробую воспользоваться этим способом.
Именно. У закрытого тикет дочернего. А мне нужно узнать, какой ордер для ныне родительского (от которого уже появился дочерний, что отметилось в его комментарии) был родительским.
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Вы принимаете политику сайта и условия использования
Добрый день, уважаемые программисты.
Столкнулся с такой задачей. Пишу советник, который должен частично закрывать сделку несколько раз при выполнении определенных условий. Для того, чтобы проверить, выполнены ли условия для следующего частичного закрытия, нужно для начала узнать, сколько раз от исходного ордера уже отщипывали кусочек лота. И это можно сделать только путем перебора всех закрытых ордеров и проверки времени открытия и направления сделки и цены открытия (все остальные параметры могут быть изменены советником, а комментарий меняется автоматически при частичном закрытии, поэтому его использовать его тоже не вариант). Вести журнал сделок с сохранением информации на жесткий диск не хочется (вряд ли выиграю по скорости - нужно файл открыть, прочитать, исправить, сохранить, закрыть).
При этом задача в том, чтобы советник был стабилен при сбое терминала, поэтому список закрытых ордеров получаю на каждом тике, но нужно решить вопрос быстродействия программы. Советник планируется запускать на нескольких парах одновременно и из-за мелкого таймфрейма список сделок быстро растет. Но из-за того, что эта же стратегия может применяться на старших таймфреймах, список отображаемой истории нужно держать хотя бы за месяц.
Так как проверку условий нужно совершать по каждому открытому на данный момент ордеру (а их может быть несколько), копирую информацию в память программы, записывая в структуру, чтобы потом осуществлять перебор в ней.
В принципе, чтобы не копировать весь список открытых ордеров (я фильтрую и собираю в массив структур только те ордеры, которые могут быть интересны самой программе в том или ином месте алгоритма), я думаю, что можно было бы узнать дату самого раннего открытого ордера из интересующих и не копировать историю младше конкретного числа. Но на практике этот подход может дать сбой, если пользователь в списке истории ордеров поставит сортировку, например, по валютной паре, объему или типу.
Больше не могу придумать никаких вариантов.
Может кто сталкивался с подобной задачей? Подскажите, как можно еще решить вопрос производительности?