Вы говорите об общей папке C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.
Вот такой же принцип нужен и для терминала в штатном режиме, а не с помощью принудительного указания общей папки к базам истории с помощью ссылок. Сейчас это хорошо работает, но просьба - реализуйте, пожалуйста эту возможность штатно с помощью указания папки к базам истории из настроек терминала.
:-)
Я уже кидал заявку , размазать песочницу с дата файлами и логами по дисковой системе для быстродействия.
Например есть SSD диски , один для системы , SSD для логов ,SSD для быстрых данных.
Ну вот хорошо бы логи на один SSD , данные на другой - сам терминал еще куда может быть тоже на SSD
Скорость обращения к данным возрастет , с учетом , что у каждого диска свой контроллер.
вы о другом ратуете - за доступ к общей базе - что бы собирать данные по одному дилингу для разных терминалоа в одной папке - у какого количества людей подобная конфигурация ?
я просто купил на 12 терабай дисков и забыл эту проблему - сейчас харды таких размеров что это не актуально.
Andrey Dik: Нет, Андрей предлагает разработчикам сделать доступ к общей папке штатной возможностью. Именно это предлагает, это обращение к Вам, а не к миллионам трейдеров.
Объяснение дано:
никто не будет делать узкое место в виде сервера (а единая база означает диспетчер доступа. и этим диспетчером не может быть файловая система с блокировкой доступа - тормозить все будут сказочно)
никто не будет делать бутылочного горлышка в системе на запись
никто не будет через бутылочное горлышко гонять десятки гигабайт данных (а их именно десятки гигабайт)
поведение тестерных агентов обосновано и разумно - они используют синхронизированную базу только на чтение
все положено на алтарь скорости и низкого латенси
Текущая архитектура очень хорошая, скоростная и защищенная. Мы не зря пятое поколение торговых платформ написали - знаем стоимость каждого решения.
никто не будет делать узкое место в виде сервера (а единая база означает диспетчер доступа. и этим диспетчером не может быть файловая система с блокировкой доступа - тормозить все будут сказочно)
Ага. В итоге прикладные программеры пишут те самые файловые диспетчера с блокировкой доступа и сказочными тормозами, т.к. другого решения в рамках MQL просто нет. Зато их душу греет магический "латенси" и другие трудноприменимые в практическом плане мантры теоретического перфоманса.
Vasiliy Sokolov: Ага. В итоге прикладные программеры пишут те самые файловые диспетчера с блокировкой доступа и сказочными тормозами, т.к. другого решения в рамках MQL просто нет. Зато их душу греет магический "латенси" и другие трудноприменимые в практическом плане мантры теоретического перфоманса.
Функция обеспечивает атомарный доступ к глобальной переменной, поэтому она может быть использована для организации мьютекса при взаимодействии нескольких одновременно работающих экспертов в пределах одного клиентского терминала.
А если нужна синхронизация между терминалами, то вариантов масса. Хоть на файлах, но через DLL мьютексы и тд. Это уже ваша работа, раз вы вышли за песочницу безопасности.
Без нашей битвы за скорость вы совсем другого класса бы получили софт. Хорошее не видимо, кажется бесплатным и само-собой разумеющимся.
Vasiliy Sokolov: Ага. В итоге прикладные программеры пишут те самые файловые диспетчера с блокировкой доступа и сказочными тормозами, т.к. другого решения в рамках MQL просто нет.
По-моему все логично. Хочешь возможностей мультитерминальности -- сделай такие возможности сам. а реализовывать ее ради двух с половиной человек немного эээ нерационально.
Тем более в подавляющем большинстве случаев эти проблемы решаются на раз-два.
А если говорить про два с половиной человека, то кастомная история нужна большему количеству людей.
Вам же сказали - что городить нужно менеджер доступа к данным из разных терминалов!
А в чем проблема при доступе разных терминалов к разным данным?! Проблем нет, но удобно если все файлы лежат в одном месте и при этом нет необходимости докачивать данные каждый раз при переносе/переустановке терминала. Но и этого разрабы не хотят делать. Для этого не нужен менеджер доступа.
Речь была о доступе 2-3 терминалов к одним и тем же данным. При этом нет проблем, достаточно того, что терминалы понимают, что уже производится запись кем то и не пытаются писать при этом. А при чтении и так проблем никак не должно быть.
Не читать, не понять, ни спорить у Вас желания нет. За этим у меня нет желания метать бисер. Я знаю костыльное решение (раз разрабы не хотят делать штатные возможности) - меня это устраивает.
xxz: А файл 2016.hcc так и вообще теоретически уже никогда не должен обновляться.
Renat Fatkhullin:
Объяснение дано:
никто не будет делать узкое место в виде сервера (а единая база означает диспетчер доступа. и этим диспетчером не может быть файловая система с блокировкой доступа - тормозить все будут сказочно)
никто не будет делать бутылочного горлышка в системе на запись
никто не будет через бутылочное горлышко гонять десятки гигабайт данных (а их именно десятки гигабайт)
поведение тестерных агентов обосновано и разумно - они используют синхронизированную базу только на чтение
все положено на алтарь скорости и низкого латенси
Текущая архитектура очень хорошая, скоростная и защищенная. Мы не зря пятое поколение торговых платформ написали - знаем стоимость каждого решения.
я это прекрасно понимаю..
т к имел честь разрабатывать операционные системы и драйвера к ним
Не не, не надо удалять слова Юрия. Он заявляет, что терминал пишет в файл на каждом тике! Это обвинение MQ в непрофессионализме, я хочу понаблюдать что сделает с ним Ренат, на слова которого ссылается Юрий. Не откажите мне в удовольствии насладиться предстоящим зрелищем.
Вы говорите об общей папке C:\Users\User\AppData\Roaming\MetaQuotes\Tester\.
Вот такой же принцип нужен и для терминала в штатном режиме, а не с помощью принудительного указания общей папки к базам истории с помощью ссылок. Сейчас это хорошо работает, но просьба - реализуйте, пожалуйста эту возможность штатно с помощью указания папки к базам истории из настроек терминала.
:-)
Я уже кидал заявку , размазать песочницу с дата файлами и логами по дисковой системе для быстродействия.
Например есть SSD диски , один для системы , SSD для логов ,SSD для быстрых данных.
Ну вот хорошо бы логи на один SSD , данные на другой - сам терминал еще куда может быть тоже на SSD
Скорость обращения к данным возрастет , с учетом , что у каждого диска свой контроллер.
вы о другом ратуете - за доступ к общей базе - что бы собирать данные по одному дилингу для разных терминалоа в одной папке - у какого количества людей подобная конфигурация ?
я просто купил на 12 терабай дисков и забыл эту проблему - сейчас харды таких размеров что это не актуально.
Нет, Андрей предлагает разработчикам сделать доступ к общей папке штатной возможностью. Именно это предлагает, это обращение к Вам, а не к миллионам трейдеров.
Объяснение дано:
Текущая архитектура очень хорошая, скоростная и защищенная. Мы не зря пятое поколение торговых платформ написали - знаем стоимость каждого решения.
Ага. В итоге прикладные программеры пишут те самые файловые диспетчера с блокировкой доступа и сказочными тормозами, т.к. другого решения в рамках MQL просто нет. Зато их душу греет магический "латенси" и другие трудноприменимые в практическом плане мантры теоретического перфоманса.
Есть - https://www.mql5.com/ru/docs/globals/globalvariablesetoncondition
Функция обеспечивает атомарный доступ к глобальной переменной, поэтому она может быть использована для организации мьютекса при взаимодействии нескольких одновременно работающих экспертов в пределах одного клиентского терминала.
А если нужна синхронизация между терминалами, то вариантов масса. Хоть на файлах, но через DLL мьютексы и тд. Это уже ваша работа, раз вы вышли за песочницу безопасности.
Без нашей битвы за скорость вы совсем другого класса бы получили софт. Хорошее не видимо, кажется бесплатным и само-собой разумеющимся.
Ага. В итоге прикладные программеры пишут те самые файловые диспетчера с блокировкой доступа и сказочными тормозами, т.к. другого решения в рамках MQL просто нет.
По-моему все логично. Хочешь возможностей мультитерминальности -- сделай такие возможности сам. а реализовывать ее ради двух с половиной человек немного эээ нерационально.
Тем более в подавляющем большинстве случаев эти проблемы решаются на раз-два.
А если говорить про два с половиной человека, то кастомная история нужна большему количеству людей.
Это вызов ?
Зарядим только один пистолет ? :-)
Вам же сказали - что городить нужно менеджер доступа к данным из разных терминалов!
А в чем проблема при доступе разных терминалов к разным данным?! Проблем нет, но удобно если все файлы лежат в одном месте и при этом нет необходимости докачивать данные каждый раз при переносе/переустановке терминала. Но и этого разрабы не хотят делать. Для этого не нужен менеджер доступа.
Речь была о доступе 2-3 терминалов к одним и тем же данным. При этом нет проблем, достаточно того, что терминалы понимают, что уже производится запись кем то и не пытаются писать при этом. А при чтении и так проблем никак не должно быть.
Не читать, не понять, ни спорить у Вас желания нет. За этим у меня нет желания метать бисер. Я знаю костыльное решение (раз разрабы не хотят делать штатные возможности) - меня это устраивает.
А файл 2016.hcc так и вообще теоретически уже никогда не должен обновляться.
Объяснение дано:
Текущая архитектура очень хорошая, скоростная и защищенная. Мы не зря пятое поколение торговых платформ написали - знаем стоимость каждого решения.
я это прекрасно понимаю..
т к имел честь разрабатывать операционные системы и драйвера к ним
Я вот вас ни как не могу понять!
Почему включаете дурочка!
Стоит простая задача сделать общедоступными в пределах одного брокера файлы типа "2017.hcc"
которые как я сейчас понял вообще обновляются раз в "пятилетку"
Ну какая здесь проблема?
Друзья, хорош цапаться. Удаляю флуд.