Discussions sur le testeur de stratégie MT5 - page 9
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Désolé, qu'est-ce que c'est ? Prix excessif ?
Je travaille avec un hébergement spécialisé qui peut héberger le VPS là où cela convient au client, NY4, LD4, donc cher mais rapide (ping 0-1ms).
Le surprix est le surprix.
Jouez avec notre visualiseur de VPS: il y a un réseau mondial et des timings précis basés sur la topologie des serveurs de tous les courtiers MetaTrader.
Il coûte 10 $ et tous les noyaux physiques sont disponibles. Une précision importante est que nous indiquons le temps net dans le protocole du serveur, et non le ping du réseau, qui est presque toujours inférieur au ping réel.
Vous parlez de la lecture de l'historique d'une zone - d'un dossier pour un groupe de terminaux, l'historique ne change pas, il est juste résolu sans problèmes. La cartographie personnalisable est connue depuis longtemps.
Ce n'est pas ça, vous avez téléchargé l'historique à partir d'un terminal et vous y avez ensuite fait référence à partir d'autres terminaux - pas de problème... ce n'est pas le problème.
Pourquoi faites-vous marche arrière ? :)))
Ou bien ne l'avez-vous pas lu attentivement ? Le seul moyen d'obtenir un argument sans parier de l'argent ? Yuri, tu es comme un enfant, honnêtement.
Tu vois, Yuri, il y a des solutions ! Et vous pourriez tout sortir de la boîte à MT !
Il s'agit simplement de l'idéologie de MT, qui n'implique pas plusieurs copies des terminaux en cours d'exécution, de sorte qu'il n'est pas nécessaire d'avoir accès à une base de données unique.
Vous écrivez 100 ticks de 100 terminaux dans un fichier... à un moment donné.
Fait une fois: https://www.mql5.com/ru/articles/1316#c4_1
Il est clair que sans DB, le seul moyen d'échanger convenablement entre terminaux sans dll, est de verrouiller un fichier et de se disputer l'accès à celui-ci comme cette boîte :
Il existe des artisans qui organisent la synchronisation de l'environnement commercial via WebRequest et le serveur intermédiaire (voir les copieurs de transactions dans Market).
Il est clair que tout cela est lent et fait des trous sur les disques durs des utilisateurs, mais que pouvons-nous faire si la base de données ne nous a pas été donnée (et ne le sera pas).
Tout est clair !
Nous parlons d'un terminal standard - qui collecte les ticks en un point ... et si 100 terminaux commencent à écrire le même tick dans un fichier, que se passera-t-il ?
La lecture de l'historique général d'une ressource mappée (dossier) ne pose pas de problème. (et cette histoire devrait être formée à partir d'un terminal, et non de 100 à la fois)
Andrey, peut-être que vous mélangez la lecture d'un HISTOR commun - et l'écriture dans un fichier ?
Le surprix est un prix inutilement élevé.
Jouez avec notre visualiseur de VPS: il y a un réseau mondial et des timings précis avec la topologie des serveurs de tous les courtiers MetaTrader.
Il coûte 10 $ et tous les noyaux physiques sont disponibles. Une précision importante est que nous indiquons le temps net dans le protocole du serveur, et non le ping du réseau, qui est presque toujours inférieur au ping réel.
Votre hébergement est une excellente solution spécifique lorsque vous devez mettre en place une EA, l'envoyer à l'hébergement et l'oublier. La meilleure solution pour de telles tâches.
Mais il n'est malheureusement pas adapté lorsque vous avez besoin de plusieurs terminaux pour accéder les uns aux autres. Cela s'explique en partie par le fait que le terminal MT n'a pas la capacité de se connecter à plusieurs comptes en même temps. Il y a d'autres tâches qui ne sont pas compatibles avec votre VPS.
A propos, votre visualisateur VPS est activement utilisé, c'est génial.
Pourquoi faites-vous marche arrière ? :)))
Ou vous ne l'avez pas lu attentivement ? Juste pour argumenter et ne pas parier de l'argent sur un argument ? Yuri, vous êtes comme un enfant, honnêtement.
vous donnez une réponse sensée !
COMMENT ÉCRIRE LE TICK d'un outil dans la base de données ! qui devrait être stocké dans la base de données par UN enregistrement avec un ID.
Vous avez 100 terminaux qui font du INSERT ...
Vous enregistrez 100 ticks de 100 terminaux dans un fichier... à un moment donné.
C'est exactement ce dont nous parlons !
Nous parlons d'un terminal standard - qui collecte les ticks en un point... et si 100 terminaux commencent à écrire le même tick dans un fichier ! que se passera-t-il ?
il n'y a pas vraiment de problème pour lire l'historique à partir d'une ressource mappée (dossier). (de plus, cette histoire devrait être formée à partir d'un terminal et non de 100 à la fois)
Andrew et peut-être que tu mélanges la lecture de l'HISTOR commun - et l'écriture dans le fichier ?
vous donnez une réponse sensée !
COMMENT ÉCRIRE LE TICK d'un outil dans la BASE ! qui doit être stockée dans la base de données par UNE entrée avec un ID !
Vous avez 100 terminaux qui font du INSERT ...
Vous ne voulez pas vous disputer ! Pourquoi devrais-je épeler une seule et même chose, encore et encore, et gratuitement ? !
Un rappel et un avertissement - vous adoptez une position erronée et nuisible pour le développement de MT.
Ne nous ridiculisons pas, d'accord ? Il ne convient pas aux hommes barbus mais déjà chauves. J'ai été clair : un dossier partagé contenant des données historiques est créé et les terminaux fonctionnent bien avec ce dossier via un lien, sans aucun problème d'accès. Cela permet vraiment d'économiser l'espace disque, qui est très limité.
Vous avez 100 terminaux qui écrivent l'histoire en même temps ?
--
Ne vous ridiculisez pas - nous voulons simplement une réponse.
COMMENT ÉCRIT-ON LE TICK d'un outil dans une BASE DE DONNÉES - il doit être stocké dans la base de données comme UN enregistrement et avec UN ID.
vous avez 100 terminaux qui écrivent des INSERTS sur la même table en même temps pour cet outil ...
p.s.
J'ai une solution - la vôtre est intéressante
Vous avez 100 terminaux qui écrivent l'histoire en même temps ?
--
Ne vous ridiculisez pas - nous voulons simplement une réponse !
COMMENT ÉCRIRE un TICK d'un outil dans une BASE DE DONNÉES - il doit être stocké dans la base de données comme UN enregistrement avec un ID.
vous avez 100 terminaux qui écrivent des INSERTS sur la même table en même temps ...
Je vais répondre pour Andrei. Si nous travaillons avec des fichiers, l'INSERT simultané est hors de question. L'INSERT n'est effectué que par le thread qui obtient l'accès au fichier en premier. Les autres obtiendront INVALID_HANDLE et ne pourront pas écrire. Le thread qui obtient le handle pourra vérifier si son enregistrement existe déjà dans le fichier ou non (en supposant que nous savons comment déterminer l'unicité de chaque enregistrement). S'il n'y a pas d'enregistrement, nous l'écrivons, si l'enregistrement a déjà été fait par quelqu'un, nous fermons l'anse.
Une autre question est que faire 100 écrivains et 100 lecteurs en même temps n'est au moins pas rationnel et peut causer des problèmes. Si possible, il ne devrait y avoir qu'un seul rédacteur. Il est également tout à fait possible de déterminer qui désigner comme rédacteur sur 100 fils.
p.s. Nous ne discuterons pas de la question de l'accès concurrentiel aux SGBD pendant plus d'une douzaine de pages. Considérant qu'il n'y a pas de BD dans MQL, nous ne discuterons pas non plus du sujet de la discussion.
Je vais répondre pour Andrei. Si nous travaillons sur des fichiers, il ne s'agit pas d'INSERTS simultanés. L'INSERT ne sera effectué que par le thread qui aura accès au fichier en premier. Les autres obtiendront INVALID_HANDLE et ne pourront pas écrire. Le thread qui reçoit le handle pourra vérifier si son enregistrement existe déjà dans le fichier ou non (en supposant que nous savons comment déterminer l'unicité de chaque enregistrement). S'il n'y a pas d'enregistrement, nous l'écrivons, si l'enregistrement a déjà été fait par quelqu'un, nous fermons l'anse.
Une autre question est que faire 100 écrivains et 100 lecteurs en même temps n'est pas rationnel et peut causer des problèmes. Si possible, il ne devrait y avoir qu'un seul rédacteur. Il est également tout à fait possible de déterminer qui désigner comme rédacteur sur 100 fils.
c'est ce que je veux dire ! et que
Vasily, il est compréhensible qu'il soit possible de se disputer le dossier à partir de 100 terminaux.
le fait que vous puissiez copier des transactions d'un terminal à l'autre en utilisant le copieur est une autre chose.
La question est que le terminal lui-même (s'il s'agit de MT4) écrit les ticks dans le fichier ticks.raw ...
mais s'il essaie d'écrire 100 terminaux à la fois dans le fichier {TERMIN}\history\{broke}\tisks.raw - une erreur se produira
C'est ce que je ne pense pas qu'Andrei comprenne.
Je peux entendre le canapé théorique grincer sous Andrei à nouveau.
p.s.
Andrei, tu es allé chercher de la graisse pour canapé ?