Когда кончатся эти мучения с подкачкой данных?

Новый комментарий
 
Ну неужели нельзя сделать по людски?

Допустим у меня есть индикатор, который использует несколько разных исторических серий (по разным символам и/или таймфреймам).

Мне нужно посчитать что-то на последних 1000 барах.
Как мне это сделать?

Я уже за..... (как это по русски ...) ...
Издевательство над здравым смыслом получается :(((
Полный бред и бардак, как будто нарочно юзерам палки в колеса вставляют ... :((

Если я в скрипте обращаюсь к Close[1000], то МТ -- ОБЯЗАН МНЕ ЕГО ДАТЬ,
безо всякого гемороя с моей стороны.

Аналогично, если мне нужны данные по другому символу или таймфрейму и я пишу:
int start()
{
     ........
      K = ArrayCopySeries(Data1, MODE_CLOSE, Sym);
      R = Data1[1000];
     ........
}


то МТ -- ОБЯЗАН дать мне значение R.

ДОЛЖЕН БЫТЬ КАКОЙ-ТО МЕХАНИЗМ ДЛЯ ЭТОГО.
Лучше если он будет прозрачен (незаметен) для пользователя.

Может уже сейчас есть какой-то способ?
Научите, я не смог его найти.

Если конечно вам наплевать на юзеров,
можете оставить как есть ...

 
В постараемся реализовать решение для автоматической подкачки "по требованию/on demand" из скриптов при первом обращении в несуществующие области чарта. К сожалению, это не так просто. Скрипт может что угодно (например элемент 1000000, да еще по всем символам) запросить и если мы будем каждый раз пытаться закачать то, чего нет, то все будет очень печально. Следующая проблема в том, что подкачка истории асинхронная и порционная(идет кусками определенной длины). То есть, скрипт желает бар номер 10000, терминал послушно начал выполнять последовательную подкачку по 256-512 баров, а все это требует времени. Можно не дождаться(или очень долго ждать) ее завершения, а что делать в это время скрипту? Ждать? Нас же смешают с грязью если эксперт будет неожиданно уходить в спячку, ожидая подкачки данных.

Естественно, появится масса кода от программистов, пишуших "в лоб" и у которых скрипты будут устраивать массовую прокачку всех символов и периодов. А что? У кого-то канал быстрый и трафик бесплатный...

Мы заботимся об общей стабильности системы и не позволяем нерационально тратить ресурсы.
Желания "хочу и все! дайте мне! вы обязаны!" недостаточно чтобы мы пошли на изменение архитектуры.

Ниже представлена статистика количества пользователей MetaTrader4 в онлайне на демо-сервере www.metaquotes.ru (обычный P4 3Ghz, RAM 1Gb) за последнюю неделю (штатные графики мониторинга из MetaTrader Administrator):
 
Я все понимаю, но ситуация которая имеется сейчас ни в какие ворота ...
То что есть, приспособлено только под простые индикаторы типа мувингов.
И главное нет никакого механизма для решения этой задачи - ни простого, ни сложного.

Синхронная/Асинхронная подкачка ..

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

Если писать индикаторы/эксперты по тем правилам, что есть сейчас,
то синхронная подкачка никак не повлияет на работу - тут она просто ненужна.
Если пользователь явно хочет получить Close[1000] и его нет в локальном кеше,
ну подождет один раз, и ничего страшного - при следующем обращении все будет в локальном кеше.

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

Про надежность.

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

Надежность есть там, где есть набор простых и понятных правил (механизмов), и эти правила обеспечивают решение необходимых задач. Если пользователь понимает эти правила функционирования системы, то он сам может отвечать за свои действия (возьмите для примера Unix/Linux). Скажите пользователю как работает механизм подкачки, и он сам решит нужно ли этим пользоваться и что при этом ожидать.
Мы заботимся об общей стабильности системы и не позволяем нерационально тратить ресурсы.
Желания "хочу и все! дайте мне! вы обязаны!" недостаточно чтобы мы пошли на изменение архитектуры.

Зачем менять архитектуру?
Все уже есть, требуется добавить самый минимум - наверное несколько строк, или несколько десятков строк в код МТ для реализации синхронного режима. Синхронный режим должен быть обязательно и думаю что его будет достаточно.

Я вам гарантирую, что нагрузка на ваш сервер возрастет незначительно и только в самом начале, при закачке в локальный кеш. И если описать как происходит подкачка и выдавать сообщение (см. выше), то никто не будет жаловаться на ожидания ее завершения.

Если вы все таки хотите дополнительно гарантировать производительность своего сервера и его доступность, добавте приоритеты подкачкам истории. Пусть они будут обратно пропорциональны глубине истории. Т.е. блок с баром от 0 до 511 имеет наибольший приоритет, блок с баром от 512 до 1023 меньший, от 1024 ... еще меньший и т.д. Будет максимальная оперативность для тех кому много не надо и возможность скачивать любую глубину истории никому не мешая.

Еще раз подчеркиваю, подкачка - это редкий единичный случай, но ее наличие делает МТ более понятным, логичным и предсказуемым.

PS. Перед каждой точкой можете добавить ИМХО,
чтобы не загромождать текст, я этого делать не стал ..
 
И главное нет никакого механизма для решения этой задачи - ни простого, ни сложного.

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

Я вам гарантирую, что нагрузка на ваш сервер возрастет незначительно и только в самом начале, при закачке в локальный кеш. И если описать как происходит подкачка и выдавать сообщение (см. выше), то никто не будет жаловаться на ожидания ее завершения.

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

Для примера с нашего сервера: тупые попытки эксперта совершить сделку без наличия средств, эксперт не обрабатывает ответ о недостаточности средств и каждые 2 секунды шлет новый запрос(в МТ4 сняты ограничения на 10 секундный интервал между сделками). Попытки шли примерно полсуток - посчитайте сколько транзакций было? Да, правильно, около 20 000 отвергнутых сделок от глупого эксперта. И таких ошибок будет еще куча.

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

Наша задача - не дать даже возможности ошибиться или завалить систему глупыми операциями. И в этом свете "отрезание рук и ног" - достаточно хорошее решение.

Кстати, мы как раз работаем над тем, чтобы избежать ошибок еще на клиентском терминале. Поэтому и подкачку тоже сделаем разумную и защищенную от ошибок.

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

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

".. вручную побегать по графикам и закачать все что нужно путем ручного скроллинга до конца графика .." - это не механизм. Это и есть издевательство над здравым смыслом ..

Вот есть у меня индекс использующий данные по 6 парам.
Пусть он запущен на чарте.
И допустим я хочу сменить таймфрейм.

Что я должен сейчас сделать?
Правильно,
- открыть 6 чартов.
- на каждом установить нужный мне таймфрейм.
- пролистать все 6 чартов (каждый по отдельности) на нужную мне глубину.
- и после этого я могу посмотреть значения моего индикатора.
Это вы называете механизмом?
(под механизмом я подразумевал средства доступные из языка)

Ладно, ждемс ...
 
Вот есть у меня индекс использующий данные по 6 парам.
Пусть он запущен на чарте.
И допустим я хочу сменить таймфрейм.

И я как раз об этом - массовые закачки по всем фронтам, превращая информационно-торговый сервер в FTP сервер. Но Вы тут не виноваты, Вы только воспользовались стандартной функцией подкачки. Так же как не виноваты остальные сотни и тысячи пользователей, которые в массе привели к тормозам... Виноват MetaQuotes, что позволил такому случится!

К счастью разработчики Апачей и прочих ВЕБ серверов для надежности и безопасности не режут страницы до 512 байт

У них другие задачи. 99% всех обычных рабочих вебсайтов в инете упадет если к ним 3000-5000-10000 (зачастую меньше) юзеров одновременно нагрянет. И заохают админы, отключая тяжелый контент и возьмутся за оптимизацию.

А брокерским компаниям важна гарантия что пользователи по-тупому массированной закачкой не лишат сервер производительности и поэтому режим - "подкачка по требованию", а не "закачать все что можно да на всю глубину". То есть, мы не пойдем на поводу тех 1% пользователей, которые желают массы информации по любому запросу.

Осенью у Альпари как раз были проблемы из-за огромного количества пользователей, которые отъедали много ресурсов, что приводило к тормозам на новостях. Больше мы такого допускать не намерены. Эффект масштаба любые простейшие запросы приводит к серьезным цифрам.
 

ДОЛЖЕН БЫТЬ КАКОЙ-ТО МЕХАНИЗМ ДЛЯ ЭТОГО.


Поддерживаю Mak'a двумя руками! Сам столкнулся с этой проблемой. По-моему, было бы идеально, если бы я мог вызвать метод LoadQuotes(string symbol, int timeframe, int bars) в init() методе. И этот метод должен гарантировать, что в любой момент у меня есть как минимум скажем 1000 последних баров нужной мне периодичности.

Еще один нюанс, с которым я столкнулся при использовании ArrayCopyRates - в данных иногда появляются "дырки". Например, я загружаю M15 данные, возвращается 2000 баров, но с пропусками, скажем есть бар на 15:30, на 15:45 - нет, а на 16:00 опять есть. Хотелось бы, чтобы такого поведения в финальной версии не было.

А по поводу нагрузкина сервер - все таки загрузка исторических данных и отсылка 20000 запросов при остсутвии денег на счету - разные виды нагрузки. Если я один раз затребовал историю и она загрузилась, то если через минуту я опять ее затребую - она не будет вновь загружаться с сервера, так как она уже у меня есть!

Если же для передачи данных использовать адаптированный под ПОСЛЕДОВАТЕЛЬНОСТЬ котировок алгоритм, то порции исторических данных можно ужать в 20-50 раз и передаваться они будут ну очень быстро :).
 
Я вас прекрасно понял.
Вы уже не первый раз повторяете одно и то же.
А вы вообще читаете то что я пишу?

Я же вам написал как избежать перегрузки сервера истории большими закачками (установкой приоритета).
Кроме того, в новой вашей архитектуре эта проблема решается просто установкой дополнительного Data Center, или нескольких.
А брокерским компаниям важна гарантия что пользователи по-тупому массированной закачкой не лишат сервер производительности и поэтому режим - "подкачка по требованию" ...

Какой сервер?
Торговый или Дата Центр?
И как я к примеру могу по-тупому лишить сервер производительности?
Ну закачаю я 1 раз 10000 баров к примеру, в следующий раз они вернутся мне из моего кеша ... Как я тут перегружу сервер?

Такое ощущение, что вы просто не хотите меня слышать,
и все время говорите не про то про что я пытаюсь вам сказать ...

У вас неплохая платформа, но без какой-то синхронизации данных из разных серий, это будет инструмент для работы с одной серией. Возможность использовать ArrayCopySeries могла бы дать многое, но без синхронизации от нее больше проблем, чем смысла. И я никак не могу понять вашего упорства ... Еще раз повторяю - введение синхронной подкачки совсем незначительно увеличит нагрузку на Дата Цент и не повлияет на все остальное.

Ладно, я устал с вами спорить попусту.
Разговор получается не по сути ...
 
Ладно, я устал с вами спорить попусту.
Разговор получается не по сути ...

Ситуация такова, что у Вас теоретические размышления, а у нас 5 лет практики разработки информационно-торговых систем. Мы уже многое испробовали и знаем проблемные места. Ибо не один раз уже в них попадали. Если что-то не делается, значит есть серьезные препятствия.
 
Renat - а если сделать дополнительную возможность загрузки истории в сервисе терминала "Архив котировок". Чтото вроде загрузить историю за start_datetime - end_datetime для пар такихто фреймов таких-то. А заодно можно чекать блоки уже загруженных котировок на корректность, и если есть несовпадения с серверными данными, то перезагружать их ("Синхронизация данных"). Двойная полезность.
Выделить под сервис отдельный сервер у ДЦ :) и все счастливы.

Не у верен что мысль новая. И даже уверен что не новая.
В связи с этим вопрос - почему так не сделали ?
Да - есть скролл графика влево. Спорное решение, но работает.
А есть ли проверка на корректность и полноту котировок ?
 
А есть ли проверка на корректность и полноту котировок ?

Корректность графика 100% проверяется через Chart->Refresh.
Для оценки неизменности используются цифровые отпечатки(хеши) базы данных, которые сравниваются с копией на торговом сервере. Если есть изменения в базе, то данные в базе подкачиваются заново.
123456
Новый комментарий
Причина обращения: