MT5 e la velocità in azione - pagina 72

 
Andrei Trukhanovich:

il più incompreso qui sei tu. non ingombrare il thread.

Buona fortuna nei vostri inutili tentativi di ottenere risultati paralleli in un modello di esecuzione sincrono ))

 

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

#
Caratteristiche e opzioni
Hosting standard
MetaTrader Forex VPS
1
Ping minimo al server di intermediazione
+
+
2
Latenza a livello di server dovuta alla memoria e alla CPU

No
3
Risorse rimanenti per le piattaforme MetaTrader
20 %
99 %
4
Allocazione flessibile delle risorse "su richiesta".
No

5
Numero di core di CPU dedicati per piattaforma
1
Non limitato
6
Volume della RAM allocata
1 GB
Fino a 3GB
7
Difficile da impostare e gestire
Relativamente alto
Minimo
8
Attivazioni di prodotti acquistati dal Marketplace
1 attivazione brucia
Non brucia

Su questo VPS le cache di CopyTicks vengono cancellate immediatamente? 3 Gb non è sufficiente - giudico dal carico sulla macchina di casa, se il terminale è ricaricato e una dozzina di EAs in una volta andrà a prendere la storia dei tick.

ChartSaveTemplate e Apply funzionano su VPS? In generale, propongo di dare una tale macchina per i test di stress.

 
fxsaber:

"Hosting normale" - con o senza shell grafica (Server Core)?

 
Aleksey Nikolayev:

"Hosting normale" - con o senza shell grafica (Server Core)?

È da qui che è stata presa la tabella.

Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
  • www.mql5.com
Универсальными средствами очень сложно добиться рекордных показателей. Обычным VPS-решением очень сложно получить по-настоящему быстрое исполнение. И мы покажем вам почему. Инфраструктура обычных VPS-решений Хостинг-провайдеры берут достаточно мощный сервер и запускают на нем много виртуальных операционных систем. Скажем, имеется машина с...
 
fxsaber:
I punti 4, 5, 6 sono per il VPS più economico.
Anche se ammetto che MT VPS è meglio se il prezzo è giusto e ci sono requisiti sufficientemente alti. Soprattutto perché i terminali non ci sono extra inutili.
 


Questo è l'intero problema, i gestori sono stupidamente eseguiti in sincronia, cioè in modo bloccante.
Rendeteli non bloccanti!


//+------------------------------------------------------------------+
//|                                                    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:


Questo è l'intero problema, i gestori sono stupidamente eseguiti in sincronia, cioè in modo bloccante.
Rendeteli non bloccanti!

Hai imparato qualche antica arte popolare, il tuo salterio non suona, o sbatti i cucchiai qui? )))

Ma cercherò di parlare nel vostro antico dialetto:

se si scrive in WinForms allo stesso modo il gestore buttonClick(oggetto sender, EventArgs e)

Sarà in grado di elaborare i clic su altri elementi WinForms?

Con la vostra visione di come sono strutturati i modelli event-driven, dovreste sicuramente scrivere prima un reclamo a Microsoft, dicendo che non hanno messo l'intera architettura correttamente: "Datemi un thread diverso per ogni battuta - cliccherò sulle battute con i miei mouse"?


Ho cercato di essere molto corretto, anche se sarebbe possibile spiegarlo solo con chiare parolacce

 
Igor Makanu:

Stai imparando una specie di antica arte popolare, il tuo salterio non suona, o sbatti i cucchiai qui? )))

Ma cercherò di parlare nel vostro antico dialetto:

se si scrive in WinForms allo stesso modo il gestore buttonClick(oggetto sender, EventArgs e)

Sarà in grado di elaborare i clic su altri elementi WinForms?

Con la vostra visione di come sono strutturati i modelli event-driven, dovreste sicuramente scrivere un reclamo a Microsoft per prima cosa, dicendo che non hanno messo l'intera architettura correttamente: "Datemi un thread diverso per ogni battuta - cliccherò sulle battute con i miei mouse"?


Cercavo di essere molto gentile, ma potevo spiegarlo solo con chiare parole di maledizione.

Andate a imparare la programmazione asincrona, sono già stufi.

 
Roman:


Questo è l'intero problema, i gestori sono stupidamente eseguiti in sincronia, cioè in modo bloccante.
Rendeteli non bloccanti!

Per favore, ditemi un esempio in cui sono necessari eventi asincroni e non è possibile farlo ora con mezzi standard.

 
Roman:

Vai a imparare la programmazione asincrona, ti stai stufando.

Capisco molto bene come funzionano le applicazioni in Win.

È meglio che impariate la storia di Python, da dove e quando sono venute queste stampelle asincrone ben chiamate? - Capite che python non è stato originariamente progettato per queste soluzioni?

Sono d'accordo che grazie a queste cose asincrone si può usarePython per soluzioni client-server, forse è figo che il frontend dell'utente possa ora usare le risorse di un server multiprocessore,

ma perché un utente in un'applicazione desktop dovrebbe avere un terminale in Win? - Bene, se avete più thread, anche se potete sincronizzarli con alcune funzioni await, rimarrà un pool comune di messaggi/eventi


Sono stufo, vi sto annoiando con tutto questo forum, non fate altro che ingombrare i thread con le vostre fantasie, non è un mio problema