MT5 et la vitesse en action - page 72

 
Andrei Trukhanovich:

la personne la plus incomprise ici, c'est vous. n'encombrez pas le fil.

Bonne chance dans vos tentatives inutiles d'obtenir des résultats parallèles dans un modèle d'exécution synchrone ;))

 

Сравнение функций обычного хостинга и форексного MetaTrader VPS

#
Caractéristiques et options
Hébergement standard
VPS MetaTrader Forex
1
Ping minimal vers le serveur du courtier
+
+
2
Latence au niveau du serveur due à la mémoire et au CPU
Oui
Non
3
Ressources restantes pour les plateformes MetaTrader*.
20 %
99 %
4
Allocation flexible des ressources "à la demande".
Non
Oui
5
Nombre de cœurs de CPU dédiés par plateforme
1
Non limité
6
Volume de la RAM allouée
1 GO
Jusqu'à 3 Go
7
Difficile à mettre en place et à gérer
Relativement élevé
Minimal
8
Activations de produits achetés sur la Place de marché
1 activation des brûlures
Ne brûle pas

Sur ce VPS, les caches de CopyTicks sont-ils effacés immédiatement ? 3 Gb n'est pas assez - je juge par la charge sur la machine de la maison, si le terminal est rechargé et une douzaine d'EA à la fois ira prendre l'histoire des ticks.

ChartSaveTemplate et Apply fonctionnent sur VPS? En général, je propose de soumettre une telle machine à des tests de résistance.

 
fxsaber:

"Hébergement normal" - avec ou sans shell graphique (Server Core) ?

 
Aleksey Nikolayev:

"Hébergement normal" - avec ou sans shell graphique (Server Core) ?

C'est de là que provient la table.

Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
  • www.mql5.com
Универсальными средствами очень сложно добиться рекордных показателей. Обычным VPS-решением очень сложно получить по-настоящему быстрое исполнение. И мы покажем вам почему. Инфраструктура обычных VPS-решений Хостинг-провайдеры берут достаточно мощный сервер и запускают на нем много виртуальных операционных систем. Скажем, имеется машина с...
 
fxsaber:
Les points 4, 5, 6 sont pour le VPS le moins cher.
Même si j'admets que le MT VPS est meilleur si le prix est correct et si les exigences sont suffisamment élevées. D'autant plus que les terminaux ne comportent pas de suppléments inutiles.
 


C'est là tout le problème, les handlers sont stupidement exécutés en synchronisation, c'est-à-dire en mode bloquant.
Rendez-les non bloquants !


//+------------------------------------------------------------------+
//|                                                    TestBlock.mq5 |
//|                        Copyright 2019, MetaQuotes Software Corp. |
//|                                             https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright "Copyright 2019, MetaQuotes Software Corp."
#property link      "https://www.mql5.com"
#property version   "1.00"

//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
{

   EventSetTimer(1);
   return(INIT_SUCCEEDED);
}

//+------------------------------------------------------------------+
//| Expert deinitialization function                                 |
//+------------------------------------------------------------------+
void OnDeinit(const int reason)
{
   Comment("");
   EventKillTimer();

}

//+------------------------------------------------------------------+
//| Expert tick function                                             |
//+------------------------------------------------------------------+
void OnTick()
{
   int count = 0;
   
   while(!_StopFlag)
   {
      Comment((string)count++);
      ChartRedraw();
      Sleep(100);      
   }
   
}

//+------------------------------------------------------------------+
//| Timer function                                                   |
//+------------------------------------------------------------------+
void OnTimer()
{
   Print("Остальные обработчики тупо заблокированы");

}

//+------------------------------------------------------------------+
//| ChartEvent function                                              |
//+------------------------------------------------------------------+
void OnChartEvent(const int id,
                  const long &lparam,
                  const double &dparam,
                  const string &sparam)
{



}
//+------------------------------------------------------------------+
//| BookEvent function                                               |
//+------------------------------------------------------------------+
void OnBookEvent(const string &symbol)
{



}
//+------------------------------------------------------------------+
 
Roman:


C'est là tout le problème, les handlers sont stupidement exécutés en synchronisation, c'est-à-dire en mode bloquant.
Rendez-les non bloquants !

Avez-vous appris des arts populaires anciens, votre psaltérion ne joue pas, ou vous tapez sur des cuillères ici ? )))

Mais je vais essayer de parler dans votre ancien dialecte :

si vous écrivez dans WinForms de la même manière le gestionnaire buttonClick(objet sender, EventArgs e)

Pourrez-vous traiter les clics sur d'autres éléments WinForms ?

Avec votre vision de la structure des modèles pilotés par les événements, vous devriez certainement commencer par écrire une plainte à Microsoft, en disant qu'ils n'ont pas mis en place correctement toute l'architecture : "Donnez-moi un fil différent pour chaque baton - je cliquerai sur les batons avec mes souris" ?


J'ai essayé d'être très correct, bien qu'il ne soit possible de l'expliquer qu'avec des gros mots clairs.

 
Igor Makanu:

Avez-vous appris une sorte d'art populaire ancien, votre psaltérion ne joue pas, ou vous tapez sur des cuillères ici ? )))

Mais je vais essayer de parler dans votre ancien dialecte :

si vous écrivez dans WinForms de la même manière le gestionnaire buttonClick(objet sender, EventArgs e)

Pourrez-vous traiter les clics sur d'autres éléments WinForms ?

Avec votre vision de la structure des modèles pilotés par les événements, vous devriez certainement commencer par écrire une plainte à Microsoft, en disant qu'ils n'ont pas mis en place correctement l'ensemble de l'architecture : "Donnez-moi un fil différent pour chaque baton - je vais cliquer sur les batons avec mes souris" ?


J'essayais d'être très gentil, mais je ne pouvais l'expliquer qu'avec des jurons clairs.

Allez apprendre la programmation asynchrone, vous en avez déjà assez.

 
Roman:


C'est là tout le problème, les handlers sont stupidement exécutés en synchronisation, c'est-à-dire en mode bloquant.
Rendez-les non bloquants !

Veuillez me donner un exemple où des événements asynchrones sont nécessaires et où il n'est pas possible de le faire maintenant par des moyens standard.

 
Roman:

Va apprendre la programmation asynchrone, tu commences à en avoir marre.

Pourquoi ? Je comprends très bien comment les applications fonctionnent dans Win.

Vous feriez mieux d'apprendre l'histoire de Python, où et quand sont apparues ces béquilles asynchrones bien nommées ? - Vous comprenez que python n'a pas été conçu à l'origine pour ces solutions ?

Je suis d'accord que grâce à ces choses asynchrones on peut utiliserPython pour des solutions client-serveur, peut-être que c'est cool que le frontend de l'utilisateur puisse maintenant utiliser les ressources d'un serveur multi-processeurs,

mais pourquoi un utilisateur dans une application de bureau aurait-il un terminal dans Win ? - Si vous avez plus de fils, même si vous pouvez les synchroniser avec des fonctions d'attente, il restera un pool commun de messages/événements.


J'en ai marre, je t'ennuie avec tout ce forum, tu ne fais qu'encombrer les fils de discussion avec tes fantasmes, ce n'est pas mon problème...