Discussion of article "Why Virtual Hosting On The MetaTrader 4 And MetaTrader 5 Is Better Than Usual VPS"

 

New article Why Virtual Hosting On The MetaTrader 4 And MetaTrader 5 Is Better Than Usual VPS has been published:

Renting a virtual server right from the MetaTrader 4 and MetaTrader 5 terminals is the optimal way to ensure uninterrupted work of your trading robots and Signal subscriptions. Essentially, it is an analogue of a VPS though it is better and more suitable for addressing needs and challenges that a trader comes across. The server can be rented straight from your MetaTrader. It takes only a couple mouse clicks for Experts Advisors, indicators, scripts together with Signal subscriptions and settings to be transferred to the virtual server. The Virtual Hosting Cloud network was developed specially for MetaTrader and has all the advantages of a native solution.

Certainly, there are alternatives to virtual hosting but a closer look reveals that they do not compete. The first thing that comes to mind is using a home computer as a budget option. It could work, however a stable internet connection and uninterrupted power supply are not guaranteed. A VPS can be rented from a suitable provider found on the internet. That could be feasible but it implies a manual search for a server having minimum latency with the required Forex-broker's. Such a puzzle does not suit everyone.

Clearly, why not skip this painful process of finding the lesser of two evils and opt for the best solution customized to meet your trading requirements. Get a virtual server right now and try it out. You have free 24 hours of hosting so you can appreciate all of the advantages of our service!


Author: MetaQuotes Software Corp.

[Deleted]  

I am, I think, one of the first users who tested hosting and made a paid subscription to it.

But, I am also a user of regular VPS.

My personal opinion:

Advantages of hosting-

1, Convenient for experimentation. Wrote an Expert Advisor, - - - and in three clicks synchronised with the hosting, looked at the results, thought, corrected - synchronised again. In the case of VPS, the file must be transferred manually. But in normal use (thrown and forgotten) it makes little difference.

2, Hosting settings do not require, but VPS must be configured for normal operation.But it is done quickly. The information is enough in free access. once done - and that's it.

3. Ping. Yes, it is convenient and quick to look in the hosting. On VPS you can find solutions no worse, but it's complicated. And in general, these minuscule differences in network latency are of little importance for the absolute majority of MT users. A trader, who tests his strategy roughly by bars and uses orders, will not even feel a 10-second ping on the result. MT is not an HFT-platform. Its ideology is "ticks are nothing, seconds are dust". About signal users - yes, ping matters. In forex - it is unlikely to be felt in any way because of the kitchen-like and decentralised nature. But on the stock exchange - you need to be able to play the signal before others to get the best price.

Disadvantages.

1. No feedback (you can't collect tick history, etc.). VPS - no problems.

2. One terminal - one hosting - this is the most serious disadvantage. On one VPS you can pack many MT-terminals, and not only MT-terminals - all in one place - simple and convenient.

3. Hosting - don't know what resources you can count on. It all depends on the behaviour of your "neighbours" . VPS - everything is more or less clear and precise - like behind a stone wall. RE-resources are enough, I think. This is so, a minor flaw.

4. Price. Based on the competitive prices for VPS and taking into account the limited capabilities of internal hosting, IMHO, a fair price for it - 3-4 $ per month. At this price, I think, Metacvots revenue for hosting will be maximum. I am not familiar with the costs.


Conclusion.-For a beginner who recently got acquainted with the computer, internal hosting - the ideal option.

 

Milliseconds are important in any trading. No matter how frequent or infrequent.

Even one requote/slip per month can easily pay off hosting. Every extra ten milliseconds increases trader's expenses. Especially in market or ECN execution modes.

In terms of resources our hosting is obviously better than limited and cut to death (are you aware of VPS overselling?) VPS services. In fact, the terminal has a couple of dozens of physical cores and 4 Gb of pure RAM at its disposal. You should use only these features correctly, without being impudent and not oppressing others. Otherwise resources will be automatically cut as well as the programme priority.

So far this is only the first version of the service and we will expand its functionality.

[Deleted]  
<br/ translate="no">

Milliseconds are important in any trading. Whether frequent or infrequent.

Even saving one requote/slippage per month easily pays off hosting. Every extra ten milliseconds increases trader's expenses. Especially in market or ECN execution modes.

Agreed. Minimal delay is better in any case.

In terms of resources our hosting is obviously better than limited and cut to death (are you aware of VPS overselling?) VPS services. In fact, the terminal has a couple of dozens of physical cores and 4 Gb of pure RAM at its disposal. You should use only these features correctly, without being impudent and not oppressing others. Otherwise resources will be automatically cut as well as the programme priority.

I'm crossing out "unknowable resources" from the disadvantages. Resources are enough for one terminal.

About overselling ... I don't know. ... I tested mine - everything is as stated.... But I will know.


So far this is only the first version of the service and we will expand the functionality.

That's what I'm most happy about. That methaquots never stop there.. Only forward!
 
Renat:

Milliseconds are important in any trading. No matter how frequent or infrequent.

Even one requote/slip per month can easily pay off hosting. Every extra ten milliseconds increases trader's expenses. Especially in market or ECN execution modes.

In terms of resources our hosting is obviously better than limited and cut to death (are you aware of VPS overselling?) VPS services. In fact, the terminal has a couple of dozens of physical cores and 4 Gb of pure RAM at its disposal. You should use only these features correctly, without being impudent and not oppressing others. Otherwise resources will be automatically cut as well as the programme priority.

So far this is only the first version of the service and we will expand the functionality.

And what does it mean to use it correctly, without being impudent? -Are the resources actually at the programme's disposal or not? When will they be automatically cut off?
 
I wanted to use your service but changed my mind. My Expert Advisor uses non-standard timeframes among other things, and in mt4 they can be obtained with the help of a script - but scripts are forbidden in your service.
 
v_maxi:
I wanted to use your service but changed my mind. My Expert Advisor uses non-standard timeframes, and in mt4 they can be obtained with the help of a script - but scripts are prohibited in your service.
Integrate the script into the Expert Advisor and everything will work.
 
v_maxi:
What does it mean to use it properly, without being cocky? -Are the resources actually at the programme's disposal or not? Automatically slaughtered when?

Actually at the program's disposal.

Arrogance is a loosely formalised concept. The approach to resource control is universal. As on any VPS hosting you will be asked to temper your appetite after killing a disc, CPU or network subsystem, so here.

Do not think that since in VPS services are not spelled out (spelled out in small print) or not announced directly, they do not have these resource rules. There are definitely rules of resource consumption. And do not be misled by the approach of "I clearly bought 1 CPU, 1 GB memory, 20 Gb disc and do not know how much network, so I can load them 100% to the end and the duty of the hoster to serve me within the resources.

In fact, in VPS can properly limit only RAM, and everything else in the form of unshared CPU, disc load (IOPS/Throughput) and network is easily killed. Which leads to a legitimate reaction of the hoster and an unsolvable question of the user "what does it mean to not get cocky?". Arguments like "you what? read the specifications, here in this and that virtualiser such resource control, so everything is rigid and correct" do not need to be cited - all this is not true and does not save in reality.


We have a rich experience of hosting client terminals for 6 years of hosting traders' championships, where we have seen absolutely mind-boggling roofies of some experts. That's why we have special versions of programmes running on hosting that know how to work with resources and logs correctly.

 
And what specific resources would there be for me to self-restrict? What resources would you not consider impudence? Regarding non-standard timeframes - I consider it your fault - it was not difficult for you to implement it. Now I have to integrate it all somehow.
 
v_maxi:
And what specific resources would there be for me to self-restrict? What resources would you not consider impudence?

Run your terminal, look at the consumed resources in the task manager, imagine running 100-200 such terminals and think about the situation from the provider's side. It is very simple.

People in society behave the same way - they leave space for others and try not to interfere. If someone starts to think that everything is only for him and he can shovel all the resources clean, the society will be dissatisfied and will ask to change.


I use the metaphor of human perception on purpose, because some technicians often forget about the norms of behaviour and look at the world as a piece of hardware that they can consume to the hilt.

 

I will tell you more about the difference between a pure VPS solution and ours.

For evaluation we take a powerful dual-core server Xeon E5-1650 3.5Ghz with a total of 24 cores, 128 gbytes of RAM, 2 x 2 tbytes of discs in RAID1 and 1 gbit network:

VPS Hosting
MetaTrader Hosting
1. Hypervisor almost any

200-500 threads
1000 mb RAM
whatsapp disc


2. 80 minimum VPS configurations of 1 CPU, 1 Gb memory, 20 gb disc


3. Windows 2008 Server Web R2


4. in fact 80% of resources will be spent on hosting operating systems

80 * 500 threads = 40 000 logical active threads on 24 physical cores
80 * 100 mb = 8 gbytes of RAM by the most minimal calculations will be spent on operating systems
80 * xxx = latent disc activity 80 operating systems kill HDD discs by IOPS limit

5. Now we are getting to the payload: 1 copy of MetaTrader 4 on 80 instances, the load is taken at a minimum

80 * 20 threads = 1,360 active threads
80 * 100 Mb = 8 Gb RAM
80 * xxx = thank God, MT is not demanding to the disc and rarely accesses it, but still there is load


6. Total load

by threads: 500 + 80 * (500 + 20) = 42,100 threads on 24 physical cores. This is a death clinic.
on memory: 1000 + 80 (100 + 100) = 17 000 megabytes out of 128 gbytes, but this is the lower limit, all memory will be used for system cache
on the disc:by IOPS limit will obviously bog down and slow down on any disc operation
by network: enough for everyone


7. Available resources

On RAM - hard limit, actual ceiling is 800 Mb for the terminal.
On CPU - only one core, and even shared (we keep 40 000 threads of operations in memory).
On the disc - what will remain after latent activity of operatons
On the network - everything is ok


8. Limit control method

Actually only alerts on CPU/Disk/Network limits + possibility to stop instances completely by external scripts.
1. host: Windows Server 2012 R2 Essentials

500 threads
1000 mb RAM
how much disk


2. 80 hosting configs on shared access to 24 CPUs, 4 Gb memory each, 2 terrabytes shared disk


3. no additional operating system


4. 1% of resources will be spent on hosting the operating system

costs accounted for in point 1



5. payload: 1 copy of MetaTrader 4 in the form of 80 instances, the load is taken as a minimum

80 * 15 threads = 1 200 active threads
80 * 20 Mb = 1.6 Gb RAM
80 * xxx = low load on disc


6. Total load

by threads: 500 + 80 * 15 = 1 , 700 threads on 24 physical cores. This is very little, the margin is huge
on memory: 1000 + 80 * 20 = 2,600 megabytes out of 128 gbytes, this is the lower limit
on disk:on IOPS limit will not bend in any way, there is a reserve
on networking: enough for everyone


7. Available resources

RAM - flexible limit, actual ceiling is 4 gb for the terminal.
On CPU - direct access to all 24 cores (500 threads of the operating system do not interfere at all).
On disc - almost without brakes, you can manage
On network - all ok


8. Limit control method

Alerts: a lot of notifications of authors by MetaQuotes ID, hoster notifications. In implementation.
CPU overrun: decrease of priority of the terminal process with recovery after load reduction
RAM overrun: notification of the terminal about starting internal cleaning
Disk overrun: notification of the terminal about automatic cleaning of logs
Special self-monitoring mode of terminals.


Look closely at the VPS variant and be horrified by the losses on providing life to independent operating systems. Giving 40 000 threads (even if many of them are sleeping) to 24 cores means that there is nothing left for useful work.

We have created an extensible cloud system for specialised hosting with minimal system costs, limits for each terminal raised to the limit and flexible resource control.

In our network terminals do not wait for the rest of the quanta of time from servicing a bunch of operating systems, but are the main consumers of resources. They have access to dozens of clean cores, maximum RAM and free discs.

And the most important thing is the emphasis on minimising network latency.

Our service is better!