MT5 and speed in action - page 72

 
Andrei Trukhanovich:

the most misunderstood one here is you. don't clutter up the thread.

Good luck in your pointless attempts to get parallel results in a synchronous execution model ))

 

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

#
Features and options
Standard Hosting
MetaTrader Forex VPS
1
Minimum ping to broker server
+
+
2
Server level latency due to memory and CPU
Yes
No
3
Resources remaining for MetaTrader* platforms
20 %
99 %
4
Flexible resource allocation 'on demand'
No
Yes
5
Number of dedicated CPU cores per platform
1
Not limited
6
Volume of allocated RAM
1 GB
Up to 3GB
7
Difficult to set up and manage
Relatively high
Minimal
8
Activations of products purchased from the Marketplace
1 activation burns
Does not burn

On this VPS are the CopyTicks caches cleared immediately? 3 Gb is not enough - I judge by load on home machine, if Terminal is reloaded and a dozen EAs at once will go to take history of ticks.

ChartSaveTemplate and Apply work on VPS? In general, I propose to give such a machine for stress tests.

 
fxsaber:

"Normal hosting" - with or without graphical shell (Server Core)?

 
Aleksey Nikolayev:

"Normal hosting" - with or without graphical shell (Server Core)?

This is where the table was takenfrom.

Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
Лучшее VPS-решение для торговли на Форекс – VPS для MetaTrader 4/5
  • www.mql5.com
Универсальными средствами очень сложно добиться рекордных показателей. Обычным VPS-решением очень сложно получить по-настоящему быстрое исполнение. И мы покажем вам почему. Инфраструктура обычных VPS-решений Хостинг-провайдеры берут достаточно мощный сервер и запускают на нем много виртуальных операционных систем. Скажем, имеется машина с...
 
fxsaber:
Points 4, 5, 6 are for the cheapest VPS.
Although I admit that MT VPS is better if the price is right and there are sufficiently high requirements. Especially since the terminals there are no unnecessary extras.
 


This is the whole problem, the handlers are stupidly executed in sync, i.e. in blocking mode.
Make them non-blocking!


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


This is the whole problem, the handlers are stupidly executed in sync, i.e. in blocking mode.
Make them non-blocking!

Did you learn some ancient folk arts, your psaltery don't play, or you bang spoons here? )))

But I'll try to speak in your ancient dialect:

if you write in WinForms the same way the buttonClick handler(object sender, EventArgs e)

Will you be able to process clicks on other WinForms elements ?

With your vision of how event-driven models are structured, you should definitely write a complaint to Microsoft first, saying that they didn't put the entire architecture in place correctly: "Give me a different thread for every batton - I'll click on the battons with my mice"?


I tried to be very correct, although it would only be possible to explain it in clear swear words

 
Igor Makanu:

Have you been learning some kind of ancient folk art, your psaltery doesn't play, or are you banging spoons here? )))

But I'll try to speak in your ancient dialect:

if you write in WinForms the same way the buttonClick handler(object sender, EventArgs e)

Will you be able to process clicks on other WinForms elements ?

With your vision of how event-driven models are structured, you should definitely write a complaint to Microsoft first, saying that they didn't put the entire architecture in place correctly: "Give me a different thread for every batton - I'll click on the battons with my mice"?


I was trying to be very nice, but it would only be possible to explain it in clear curse words.

Go and learn asynchronous programming, are fed up already.

 
Roman:


This is the whole problem, the handlers are stupidly executed in sync, i.e. in blocking mode.
Make them non-blocking!

Please tell me an example where asynchronous events are needed and it is not possible to do it now by standard means.

 
Roman:

Go and learn asynchronous programming, you're getting fed up.

Why? I understand very well how applications work in Win.

You better learn the history of Python, where and when did these well-named asynchronous crutches come from? - You understand that python wasn't originally designed for these solutions?

I agree that thanks to these asynchronous things you can usePython for client-server solutions, maybe it's cool that the user's frontend can now use the resources of a multi-processor server,

but why would a user in a desktop application have a terminal in Win? - Well, if you get more threads, even if you can synchronize them with some await-functions, a common pool of messages/events will remain


I'm sick of it, I'm boring you with this whole forum, you just clutter up the threads with your fantasies, it's not my problem