forex-scalping.com

Summer is when my VPS gets lazy and so do I. Thin August mornings hide problems because nothing moves fast enough to expose them, and then September arrives and the first busy London open shows you the machine has been degrading for weeks.

This year I kept a weekly check every Sunday evening from mid-July to the first week of September. Same five items, ten minutes, written into a small text file rather than ticked from memory.

Ping from the VPS to the trade server, ten samples, median and worst. My median sat between 1.1 and 1.4 ms all summer, but the worst sample crept from 3 ms to 19 ms in mid-August. Turned out the provider had moved me to a busier host.

Free disk space, because MT4 logs grow quietly. One terminal had 2.3 GB of journal files.

Clock drift against a time server. Anything over half a second and I resync.

Whether the terminals restarted cleanly after the weekend.

A test market order on a demo account at Sunday open, just to see the round trip.

The calibration part is deciding what counts as a fail. In summer I tightened my worst-ping limit rather than loosening it, precisely because thin markets forgive slow machines and I don't want to learn that in a fast one.

The demo order at Sunday open is the one I'd question. On a lot of setups the demo server sits on a different machine, sometimes a different data centre, from the live one. So a clean round trip on demo tells you the terminal works, but not much about the path your real orders take.

I'd rather send a minimum-size live order on a quiet pair a bit after the open, once spreads come in, and log the execution time from the journal.

Ten ping samples is also thin for spotting the sort of thing you found. Your 19 ms worst case might have been one bad sample or a pattern. I run a small script that pings every few seconds for an hour and keeps the median and the 95th or 99th percentile.

A host move like yours shows up as the tail getting fat while the median barely changes, which is exactly what you saw.

Good catch on the journal files. 2.3 GB is plenty to slow a terminal on a small VPS disk. Do you clear them by hand or have something deleting logs older than a set number of days?

The weekly check catches what drifts over a summer. A couple of things on my VPS break inside a single week, though, and a Sunday test never sees them.

Windows updates are the first. Patch Tuesday lands on the second Tuesday of the month, and on an image with automatic restarts the terminal can come back with algo trading switched off. I set active hours to cover 06:00 to 22:00 London and check the last boot time on Wednesday as well as Sunday.

The second is RAM. Four MT4 terminals with a dozen charts each grew from about 1.1 GB to 1.9 GB between Monday and Thursday on my box, and on a 2 GB plan that means swapping to disk just as the London open gets busy. So I log memory next to the ping numbers and restart the terminals on Wednesday evening.

Since your provider moved you to a busier host once, CPU steal time might be worth watching if you can see it. On shared hosts it tends to climb before ping does.

Have you found a way to read steal time from inside a Windows VPS? On Linux it's one column in top, but I've never seen a clean equivalent on the Windows side.