All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Alexhost benchmark and review
@alexhost approached me and provided a VPS for testing for 2 - 4 weeks, depending on my needs. In return I was asked to make an unbiased benchmark and review. To support that (unbiased and fair) they allowed me to pick and "purchase" one of their VPS products with the invoice "paid" by them, so as to make sure that what I tested was just a VPS any customer could/would get. A decent approach which I liked, kudos to Alexhost.
The VPS I chose ("P2" in Moldovia) was one I considered to be interesting to many here. It comes with 2 Platinum vCores, 4 GB memory, 40 GB NVMe, and 1 Gb/s, unlimited traffic AFAIK (didn't verify). This system is described as a VDS (without naming it such). Their website says
alexhost "Platinum" webpage says:
Guaranteed Resources with No Overselling
Each VPS receives dedicated CPU, RAM, and storage allocations, preventing performance degradation due to shared workloads
(verbatim quote)
Which boils down to 'VDS'. The reason I stress that point somewhat is the price, €12/mo (or about €122/yr). If that server really is a VDS that price, especially when considering the current situation, that is kind of attractive.
I'll return to that point ...
This is based on well over 300 benchmark runs over about 2 weeks day and night. First as usual sysinfo, processor and memory performance
Version 2.5.0a, (c) 2018+ jsg (->lowendtalk.com)
Machine: amd64, Arch.: amd64, Model: QEMU Virtual CPU version 2.5+
OS, version: FreeBSD 14.4, Mem.: 3.989 GB
CPU - Cores: 2, Family/Model/Stepping: 15/107/1
Cache: 32K/32K L1d/L1i, 2M L2, 16M L3
Std. Flags: fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36
cflsh mmx fxsr sse sse2 htt sse3 ssse3 cx16 sse4_1 sse4_2 x2apic
popcnt aes hypervisor
Ext. Flags: syscall nx lm lahf_lm
AES? Yes
Nested Virt.? No
HW RNG? No
ProcMem SC [MB/s]: avg 191.4 - min 36.7 (19.2 %), max 410.1 (214.2 %)
ProcMem MA [MB/s]: avg 448.3 - min 302.1 (67.4 %), max 617.8 (137.8 %)
ProcMem MB [MB/s]: avg 453.5 - min 295.1 (65.1 %), max 621.2 (137.0 %)
ProcMem AES [MB/s]: avg 1131.5 - min 721.5 (63.8 %), max 1267.4 (112.0 %)
ProcMem RSA [kp/s]: avg 63.2 - min 36.7 (58.1 %), max 82.8 (131.0 %)
Hmmm, no hardware random support and also no nested virtualization which I personally don't care about but you might.
Way more grave: no AVX2!
The AES performance is OK (roughly in Epyc ballpark), RSA performance is disappointing though.
THE major question though is whether it's really a VDS (as promised). To answer that in as fair a way possible, I looked up the numbers of a known to be a VDS server, an (older) netcup Xeon Gold root server ("VDS") I once had and benchmarked:
ProcMem SC [MB/s]: avg 181.1 - min 72.8 (40.2 %), max 295.2 (163.0 %)
ProcMem MA [MB/s]: avg 534.0 - min 506.4 (94.8 %), max 570.8 (106.9 %)
ProcMem MB [MB/s]: avg 542.2 - min 511.0 (94.2 %), max 564.0 (104.0 %)
which btw did have all flags passed through ...
See the difference (look at "min" and "max" aka the "spread")? Sorry alexhost, but the comparison makes it clear as glass: your in all but name VDS is no VDS but a bog standard VPS, a somewhat less overcrowded VPS at best!
OK, maybe the NVMe is a real speed demon (as advertised), let's take a look ...
--- Disk 4 KB - Buffered ---
Write seq. [MB/s]: avg 2.65 - min 1.06 (39.9%), max 3.92 (147.7%)
Write rnd. [MB/s]: avg 2.64 - min 1.18 (44.7%), max 3.91 (148.1%)
Read seq. [MB/s]: avg 9.66 - min 3.70 (38.3%), max 17.01 (176.1%)
Read rnd. [MB/s]: avg 8.68 - min 3.63 (41.8%), max 15.09 (173.9%)
--- Disk 4 KB - Sync/Direct ---
Write seq. [MB/s]: avg 2.66 - min 1.23 (46.2%), max 3.87 (145.4%)
Write rnd. [MB/s]: avg 2.65 - min 1.32 (49.9%), max 3.90 (147.3%)
Read seq. [MB/s]: avg 9.69 - min 3.38 (34.9%), max 17.71 (182.8%)
Read rnd. [MB/s]: avg 8.70 - min 2.92 (33.6%), max 15.45 (177.6%)
--- Disk 64 KB - Buffered ---
Write seq. [MB/s]: avg 20.68 - min 10.52 (50.9%), max 29.42 (142.2%)
Write rnd. [MB/s]: avg 26.77 - min 12.99 (48.5%), max 39.38 (147.1%)
Read seq. [MB/s]: avg 1107.29 - min 276.86 (25.0%), max 2518.22 (227.4%)
Read rnd. [MB/s]: avg 110.82 - min 51.71 (46.7%), max 183.01 (165.1%)
--- Disk 64 KB - Sync/Direct ---
Write seq. [MB/s]: avg 4.89 - min 2.99 (61.2%), max 9.07 (185.6%)
Write rnd. [MB/s]: avg 3.20 - min 2.04 (63.8%), max 5.49 (171.7%)
Read seq. [MB/s]: avg 989.14 - min 355.66 (36.0%), max 1968.75 (199.0%)
Read rnd. [MB/s]: avg 109.72 - min 48.63 (44.3%), max 183.71 (167.4%)
--- Disk 1 MB - Buffered ---
Write seq. [MB/s]: avg 25.78 - min 13.39 (51.9%), max 36.07 (139.9%)
Write rnd. [MB/s]: avg 61.02 - min 30.33 (49.7%), max 87.66 (143.7%)
Read seq. [MB/s]: avg 1918.06 - min 777.74 (40.5%), max 3921.79 (204.5%)
Read rnd. [MB/s]: avg 332.65 - min 198.81 (59.8%), max 543.47 (163.4%)
--- Disk 1 MB - Sync/Direct ---
Write seq. [MB/s]: avg 14.06 - min 9.10 (64.7%), max 20.19 (143.6%)
Write rnd. [MB/s]: avg 14.15 - min 10.52 (74.4%), max 21.08 (149.0%)
Read seq. [MB/s]: avg 1939.06 - min 813.91 (42.0%), max 3723.49 (192.0%)
Read rnd. [MB/s]: avg 332.43 - min 219.89 (66.1%), max 542.78 (163.3%)
--- Disk IOps (Sync/Direct, 4 KB/4 threads) ---
Write seq. [MB/s]: avg 8.23 - min 3.72 (45.2%), max 11.79 (143.2%)
IOps : avg 2107.81 - min 952.81 (45.2%), max 3017.08 (143.1%)
Nuh, disappointing again, 8.23 MB/s and a bit over 2000 IOps (max 3000 and a beestick) in 4k/4t is not even bog standard but actually not far away from crappy and certainly not what one expects from a €12/mo server.
Let's see whether at least their connectivity shines.
--- Europe ---
NO TRH mirror.archlinux.no [F: 0]
DL [Mb/s]: avg 192.1 - min 99.5 (51.8%), max 204.0 (106.2%)
Ping [ms]: avg 60.4 - min 0.0 (0.0%), max 205.3 (339.9%)
Web ping [ms]: avg 62.2 - min 0.0 (0.0%), max 211.0 (339.3%)
UK LON lon.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 214.0 - min 70.5 (32.9%), max 246.0 (114.9%)
Ping [ms]: avg 57.0 - min 0.0 (0.0%), max 207.5 (364.1%)
Web ping [ms]: avg 58.3 - min 0.0 (0.0%), max 207.5 (356.2%)
NL AMS nl.mirrors.clouvider.net [F: 2]
DL [Mb/s]: avg 240.3 - min 0.0 (0.0%), max 281.9 (117.4%)
Ping [ms]: avg 49.3 - min 0.0 (0.0%), max 213.0 (431.8%)
Web ping [ms]: avg 53.3 - min 0.0 (0.0%), max 213.0 (399.8%)
DE FRA mirror.plusline.net [F: 0]
DL [Mb/s]: avg 295.0 - min 90.9 (30.8%), max 342.9 (116.2%)
Ping [ms]: avg 39.3 - min 0.0 (0.0%), max 185.4 (471.6%)
Web ping [ms]: avg 42.6 - min 0.0 (0.0%), max 191.9 (450.3%)
FR PAR mirror.in2p3.fr [F: 0]
DL [Mb/s]: avg 215.4 - min 90.7 (42.1%), max 229.7 (106.6%)
Ping [ms]: avg 55.8 - min 0.0 (0.0%), max 190.8 (342.2%)
Web ping [ms]: avg 77.5 - min 0.0 (0.0%), max 539.9 (697.0%)
CH ZUR mirror.metanet.ch [F: 0]
DL [Mb/s]: avg 248.0 - min 63.0 (25.4%), max 280.5 (113.1%)
Ping [ms]: avg 46.4 - min 41.5 (89.5%), max 189.5 (408.6%)
Web ping [ms]: avg 54.0 - min 41.7 (77.2%), max 942.1 (1744.8%)
ES MAD mirror.raiolanetworks.com [F: 0]
DL [Mb/s]: avg 161.5 - min 67.8 (42.0%), max 179.1 (110.9%)
Ping [ms]: avg 72.7 - min 0.0 (0.0%), max 290.0 (399.1%)
Web ping [ms]: avg 80.0 - min 0.0 (0.0%), max 1210.3 (1512.6%)
RO BUC mirrors.hosterion.ro [F: 0]
DL [Mb/s]: avg 549.1 - min 96.9 (17.7%), max 893.8 (162.8%)
Ping [ms]: avg 13.5 - min 0.0 (0.0%), max 172.5 (1279.6%)
Web ping [ms]: avg 15.5 - min 0.0 (0.0%), max 172.5 (1111.6%)
RU MOS mirror.yandex.ru [F: 0]
DL [Mb/s]: avg 165.6 - min 55.4 (33.4%), max 193.7 (116.9%)
Ping [ms]: avg 65.5 - min 0.0 (0.0%), max 202.2 (308.6%)
Web ping [ms]: avg 105.3 - min 0.0 (0.0%), max 440.4 (418.1%)
--- Asia / Oceania ---
RU SIB mirror.truenetwork.ru [F: 0]
DL [Mb/s]: avg 102.4 - min 62.4 (61.0%), max 110.2 (107.7%)
Ping [ms]: avg 108.7 - min 0.0 (0.0%), max 226.0 (207.9%)
Web ping [ms]: avg 117.4 - min 0.0 (0.0%), max 252.3 (214.9%)
IN MUM mirrors.piconets.webwerks.in [F: 0]
DL [Mb/s]: avg 71.9 - min 39.2 (54.5%), max 80.0 (111.4%)
Ping [ms]: avg 150.6 - min 0.0 (0.0%), max 308.5 (204.8%)
Web ping [ms]: avg 200.9 - min 0.0 (0.0%), max 1486.5 (740.0%)
SG SGP mirror.jingk.ai [F: 10]
DL [Mb/s]: avg 51.4 - min 0.0 (0.0%), max 58.6 (114.0%)
Ping [ms]: avg 201.1 - min 0.0 (0.0%), max 351.0 (174.6%)
Web ping [ms]: avg 294.7 - min 0.0 (0.0%), max 1010.8 (343.0%)
CN HKG mirrors.xtom.hk [F: 2]
DL [Mb/s]: avg 49.3 - min 0.0 (0.0%), max 52.7 (106.7%)
Ping [ms]: avg 219.4 - min 0.0 (0.0%), max 228.7 (104.3%)
Web ping [ms]: avg 225.2 - min 0.0 (0.0%), max 302.0 (134.1%)
CN BEJ mirrors.bfsu.edu.cn [F: 7]
DL [Mb/s]: avg 47.1 - min 0.0 (0.0%), max 62.7 (133.3%)
Ping [ms]: avg 214.9 - min 0.0 (0.0%), max 432.5 (201.2%)
Web ping [ms]: avg 236.8 - min 0.0 (0.0%), max 1039.4 (439.0%)
JP TOK ftp.udx.icscoe.jp [F: 0]
DL [Mb/s]: avg 37.8 - min 25.4 (67.3%), max 41.9 (110.7%)
Ping [ms]: avg 299.5 - min 0.0 (0.0%), max 447.0 (149.2%)
Web ping [ms]: avg 300.4 - min 0.0 (0.0%), max 447.0 (148.8%)
AU SYD mirrors.xtom.au [F: 0]
DL [Mb/s]: avg 40.9 - min 28.9 (70.6%), max 42.5 (104.0%)
Ping [ms]: avg 274.5 - min 0.0 (0.0%), max 420.9 (153.3%)
Web ping [ms]: avg 339.6 - min 0.0 (0.0%), max 493.7 (145.4%)
--- Africa ---
KE NAI mirror.liquidtelecom.com [F: 6]
DL [Mb/s]: avg 46.5 - min 0.0 (0.0%), max 64.7 (139.2%)
Ping [ms]: avg 227.8 - min 0.0 (0.0%), max 354.2 (155.5%)
Web ping [ms]: avg 239.9 - min 0.0 (0.0%), max 838.8 (349.6%)
ZA, WEC archlinux.za.mirror.allworldit.com [F: 0]
DL [Mb/s]: avg 49.2 - min 24.1 (49.0%), max 61.4 (124.8%)
Ping [ms]: avg 217.4 - min 185.5 (85.3%), max 385.2 (177.2%)
Web ping [ms]: avg 238.5 - min 186.7 (78.3%), max 446.7 (187.3%)
--- Americas ---
CA MTL speedtest.mtl2.ca.leaseweb.net [F: 0]
DL [Mb/s]: avg 80.6 - min 39.0 (48.3%), max 91.5 (113.5%)
Ping [ms]: avg 140.5 - min 0.0 (0.0%), max 287.3 (204.5%)
Web ping [ms]: avg 145.3 - min 0.0 (0.0%), max 720.4 (495.9%)
US NYC nyc.mirrors.clouvider.net [F: 4]
DL [Mb/s]: avg 83.6 - min 0.0 (0.0%), max 95.1 (113.7%)
Ping [ms]: avg 127.2 - min 0.0 (0.0%), max 271.3 (213.3%)
Web ping [ms]: avg 133.5 - min 0.0 (0.0%), max 301.4 (225.7%)
US ASH ash.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 88.0 - min 48.4 (54.9%), max 95.6 (108.6%)
Ping [ms]: avg 133.3 - min 0.0 (0.0%), max 288.4 (216.3%)
Web ping [ms]: avg 134.7 - min 0.0 (0.0%), max 288.4 (214.2%)
US PIB mirror.pit.teraswitch.com [F: 0]
DL [Mb/s]: avg 80.1 - min 40.4 (50.5%), max 88.2 (110.1%)
Ping [ms]: avg 135.5 - min 0.0 (0.0%), max 283.7 (209.4%)
Web ping [ms]: avg 141.0 - min 0.0 (0.0%), max 301.1 (213.5%)
US MIA speedtest.mia11.us.leaseweb.net [F: 0]
DL [Mb/s]: avg 70.1 - min 46.3 (66.1%), max 74.5 (106.3%)
Ping [ms]: avg 159.0 - min 153.1 (96.3%), max 302.0 (190.0%)
Web ping [ms]: avg 164.6 - min 153.1 (93.0%), max 331.7 (201.5%)
US CHI ord.mirror.rackspace.com [F: 0]
DL [Mb/s]: avg 79.7 - min 32.2 (40.5%), max 86.4 (108.4%)
Ping [ms]: avg 131.9 - min 0.0 (0.0%), max 239.6 (181.7%)
Web ping [ms]: avg 193.0 - min 0.0 (0.0%), max 854.2 (442.5%)
US ATL atl.speedtest.clouvider.net [F: 7]
DL [Mb/s]: avg 74.5 - min 0.0 (0.0%), max 85.2 (114.4%)
Ping [ms]: avg 136.9 - min 0.0 (0.0%), max 277.7 (202.9%)
Web ping [ms]: avg 143.9 - min 0.0 (0.0%), max 288.9 (200.8%)
US PHO phx.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 60.7 - min 28.0 (46.2%), max 65.4 (107.7%)
Ping [ms]: avg 182.9 - min 170.8 (93.4%), max 336.7 (184.1%)
Web ping [ms]: avg 189.6 - min 172.9 (91.2%), max 958.5 (505.6%)
US PTL mirrors.cat.pdx.edu [F: 42]
DL [Mb/s]: avg 39.2 - min 0.0 (0.0%), max 62.3 (158.8%)
Ping [ms]: avg 188.5 - min 183.9 (97.5%), max 339.9 (180.3%)
Web ping [ms]: avg 196.7 - min 183.9 (93.5%), max 1008.8 (512.9%)
US LAX la.speedtest.clouvider.net [F: 0]
DL [Mb/s]: avg 59.2 - min 26.0 (44.0%), max 65.9 (111.3%)
Ping [ms]: avg 184.4 - min 0.0 (0.0%), max 336.8 (182.6%)
Web ping [ms]: avg 194.6 - min 0.0 (0.0%), max 650.5 (334.4%)
US SJO mirrors.xtom.us [F: 0]
DL [Mb/s]: avg 56.2 - min 33.9 (60.3%), max 60.0 (106.9%)
Ping [ms]: avg 199.5 - min 0.0 (0.0%), max 346.4 (173.6%)
Web ping [ms]: avg 204.1 - min 0.0 (0.0%), max 346.4 (169.7%)
US SEA speedtest.sea11.us.leaseweb.net [F: 26]
DL [Mb/s]: avg 47.5 - min 0.0 (0.0%), max 61.9 (130.4%)
Ping [ms]: avg 190.3 - min 0.0 (0.0%), max 357.1 (187.6%)
Web ping [ms]: avg 194.1 - min 0.0 (0.0%), max 357.1 (184.0%)
BR SPA mirrors.ic.unicamp.br [F: 0]
DL [Mb/s]: avg 40.4 - min 25.5 (63.0%), max 44.2 (109.2%)
Ping [ms]: avg 275.1 - min 0.0 (0.0%), max 476.7 (173.3%)
Web ping [ms]: avg 280.0 - min 0.0 (0.0%), max 476.7 (170.2%)
BR CUR archlinux.c3sl.ufpr.br [F: 3]
DL [Mb/s]: avg 39.0 - min 0.0 (0.0%), max 43.2 (110.9%)
Ping [ms]: avg 279.5 - min 0.0 (0.0%), max 478.8 (171.3%)
Web ping [ms]: avg 291.2 - min 0.0 (0.0%), max 1318.0 (452.6%)
CL SAN mirror.anquan.cl [F: 40]
DL [Mb/s]: avg 29.2 - min 0.0 (0.0%), max 45.3 (154.9%)
Ping [ms]: avg 255.9 - min 0.0 (0.0%), max 395.2 (154.4%)
Web ping [ms]: avg 278.5 - min 0.0 (0.0%), max 402.1 (144.4%)
CL SAN elmirror.cl [F: 37]
DL [Mb/s]: avg 33.3 - min 0.0 (0.0%), max 47.5 (143.0%)
Ping [ms]: avg 245.6 - min 237.5 (96.7%), max 385.3 (156.8%)
Web ping [ms]: avg 255.6 - min 237.6 (93.0%), max 394.0 (154.2%)
Europe - Not great nor poor, boring I'd say. With one exception, 500+ Mb/s to RO, Bucarest (duh). Plus some routing mysteries like e.g. ca. 40 ms to DE, Fra, but 55 ms to FR, Paris. Hint: the route goes via kiev, Bratislava, Vienna, Munich, Milano, Marseille (all Cogent), gets handed over to Renater which transports it to Paris within 2 or so milliseconds, while packets to DE, Fra also start with the yuck Cogent kiev route but get handed over (after a nonsensical 25 ms detour, yuck) to twelve 99 quickly in Bucharest which not surprisingly is doing a good job.
Well, one could say that thanks to Cogent your packets get to travel a lot (needlessly) and to see the world for €12/mo *g
Asia / Oceania - so, so. Some routes go via RETN or GSL and are pleasantly decent, but some (e.g. to SGP) first make an insane (no surprise) detour via the Atlantic(!) before they get handed over to GTT which the finishes the job (morbidly fucked up by Cogent) quite quickly.
Frankly, much if not most routing done via Cogent for me personally is reason enough to not buy from alexhost.
The China mainland results are quite decent though, probably because Cogent at least doesn't cross the Atlantic but Chinamobile gets the packets "early" in DE, Fra and then does a decent job. Japan is properly fucked though because derpent, uhm, Cogent hands over only in Seattle. Result: about 300 ms travel time, yuck.
Kind of positive again, Ozzyland because GSL grabs the packets early on in BG, Sofia.
Africa - OK (the packets get to a real carrier relatively early in London or Lissabon, of course only after the insane derpent ride via kiev).
Americas - Relatively decent, certainly not even near to great but acceptably decent. Bonus: Almost all LATAM targets reached and even within tolerable time.
Diverse bits and pieces:
They have a really old FreeBSD template only. So I asked support if they support install from ISO; I expected a "yes" plus a link to a KB or a How-to. But nope, the response was that, sorry, install from ISO is not available because (an excuse along the line of) the virtualizer doesn't support it.
(a) that's BS because in VNC I even saw the boot options which did include CD-ROM/DVD (Proxmox, duh!)
(b) Seriously? You demand €12/mo and don't support installing from an ISO? GFY!
So I installed their stone-age FreeBSD template (way better though than most I've seen, kudos!) and then updated the system. Cumbersome and time consuming but alas ...
Summary: If this was a private discussion with a friend I'd simply say "you get better from diverse romanian providers for way less money" and be done. But this is an official review, alexhost was generous and kind to me, and their chief [whatever] officer was friendly and seems to genuinely want to run a fine hosting business, so I'll try to put it more constructively:
The problem is price. You see, for more than 10 euros a month potential customers expect an adequate good product, especially here on LET. And the product simply isn't good or adequate; it's super-expensive yet in the middle field at best (and frankly, that's already putting it with honey and sugar).
What would "adequate" be?
Good service and support that is, "yes, of course install from ISO is supported. Details in our How-to [link]. Feel free to contact us in case you need help" instead of "nuh, not supported cause [some cheap lie]".
Decent connectivity. I get it, twelve 99 isn't the cheapest and I'd also accept less famous carriers - but NOT Cogent or HE! Not for €12/mo! Plus, at the very least, push those derpent people to give you decent or at least not insane routes!
Honesty. Do not push marketing lies down our throat! Do not make a bog standard VPS (granted with a nice processor) look as if it was a VDS!
Also don't make noise about how great and super-fast your NVMes are when in fact you actually hand out overcrowded mediocre drives.
Again: For €2/mo I'd call your VPS attractive - theoretically; because practically your connectivity is so brutally derpent crippled that I'd think twice before buying it for €1.50/mo.
But for €12/mo (certainly not only) I expect a decent product, something that's clearly and undisputably above €12/Yr products. Decent not necessarily meaning great or unearthly fast connectivity, but at least about as good as somewhat lower priced products.
I do however have quite a few VPS for €20/Yr or less that can run circles around the product I benchmarked and reviewed from alexhost.
Verdict: sorry, not recommended, even stay away!

Comments
So to make sure that it was unbiased they provisioned your VPS manually with the purpose of testing its performance?
Maybe I shouldn’t be overly critical since your conclusion was negative anyway, but that doesn’t make any sense to me.
No, he purchased it and they just paid the invoice, but it was set up as if he was anyone else buying a VPS.
How do they have less control over the povisioning this way than if they just gave him the VPS details? The only difference is it goes through WHMCS. They in-part manually provisioned him the moment he identified his order, and had every possibility to change how to provision it. It’s not at all like anyone else buying a VPS because AlexHost wouldn’t provision them manually with the intent of creating a VPS for a reviewer.
Did they just mark it as paid and have the system set it up however it wanted or did they mark it as paid and routed it to a relatively empty hypervisor? We’ll never know.
Just like we’ll never know if they would have done this or not if they just DM’d him the VPS details.
The WHMCS difference is cosmetic.
I like the way I got the test VPS, which btw @forest got right.
Of course a provider can cheat, but they didn't know it was me when I ordered, it could have been any customer; I only told them the order/invoice number afterwards and they "paid" the invoice.
@emgh seems to have got it wrong and/or missed the point. Unless @alexhost had malicious intent they could NOT cheat. And in fact they wanted me to be sure that the VPS I tested was one like any other any customer might have purchased.
Also note that timing was critical and I was not asked to inform them ASAP, I could just as well have told them a day later. Anyway, when I did inform them I already knew "my" VPS.
While my verdict is "stay away" I do not have any reason to doubt their good intentions re my test VPS. Besides their connectivity is what it is and wouldn't be any better on a hand-selected VPS.
Anyway, kudos for their good intention and their honest interest (which btw is yet another point against emgh's suspicion).
I think what @emgh is saying is the minute you gave them the order/invoice number for them to mark it as 'paid' that was enough for them to potentially identify the VPS as yours and change things in the backend to perform better for a review
I think the purpose is to "keep honest people honest". If AlexHost was going to act maliciously, sure this wouldn't stop them. But if they're manually provisioning the server, the temptation to choose a more lightly-loaded node is there.
I mean it was obviously an appearance thing and we could probably have endless fun arguing the point if the performance approached excellence, but since it didn't..
So the temptation is there if you provision it 100% manually but if it's a dropdown to select a hypervisor it's not? How does that make any sense?
Also, note how the OP frames it. He frames it as proof. He made sure. Now we're debating something else. My point was quite simple: He didn't "make sure". He made sure of nothing really.
No, see above. You said:
But you didn't make sure of anything. You accomplished the exact same thing as getting the VPS details in a DM only with extra cosmetic steps. The logic is fundamentally flawed and so is the reasoning behind it.
What does this even mean? You got the VPS before the invoice was marked as paid?
Yes, maybe, but also: no, because (a) at that point in time I already had full access to the VPS and highly likely would have noticed a swap, (b) that scheme was proposed by them. Why doing a swap after their scheme, when I would have accepted a provided for free VPS like usual? And (c) the VPS I tested was so mediocre that it makes no sense to assume it was a secretely replaced "winner server".
More of a side note maybe interesting, based on my experience I'd say that most if not all all VPS I got for testing so far have not been "winner servers" but standard ones or on a less crowded node at worst.
Your view seems to be based on the assumption that the provider is malicious. My take, supported by quite some evidence though is that what @alexhost offered was intended as "see, nothing up our sleeves".
Btw, they did not even know which VPS (platinum series or another) and which model (P1, P2, P3, ...) I would pick.
Was the VPS you got in DM the same VPS that you got in WHMCS or were they different VPS?
Not at all, it's based on the fact that you wrote:
When the truth is:
I guess and hope that they're honest.
They probably knew this when you shared your account details with them to mark the invoice as paid and set it up?
Yet another wrong assumption. Here's what happened and in what order:
Note that this is the earliest point in time they might have seen a clue (because only few customers install BSD). At least until this point I could have been any customer.
At the latest from that point on it would have been very difficult for them to swap my VPS without me noticing.
Followed by more paranoia and ignorance of what actually happened from you, e.g.
>
Neither guessing nor hope necessary. Just read what I wrote above about how it actually was.
Just read what I wrote above about how it actually was.
@jsg - Thank you.
I know your reviews follow the same format / procedures. So whether people agree or disagree on the procedures to me is irrelevant - they are consistent.
So unless you have a personal bias either for or against a provider I don't see how your conclusions are inaccurate.
As far as provisioning, yes the provider could of course bias the results, but really how else could this procedure be done?
It wasn't an assumption it was a question. The question mark is the general indicator of a question and it's widely used as this around the world.
So they manually marked it as active and set it up with no payment and you're claiming they had no idea it was yours? Doesn't make any sense at all.
Buy, test, get refunded.
not everyone is rich like you
In a perfect world yes, but in reality, why would jsg take the risk especially if the review was not positive.
So the point is that they're honest enough to not provision jsg in any different way but not honest enough to not scam him out of his money?
So, this is more of a WTF... If you order a server, they fully provision it and supply login details before you've paid the invoice?
How do they stop people abusing that? Seems crazy if so.
A better way of doing it would be for you to pay the invoice yourself, just like any other customer, and they return you the money after the review period. Maybe you raise a ticket, at that point identifying your server / account as the one doing the review. Of course, even that could be gamed as you might be the only person buying a server / creating an account that week if there's no ongoing offer.
Yes, but it sounds like what they did could still have been gamed if they were malicious. Whether they did that or not, is another matter. The fact that your review wasn't especially positive leads me to conclude they probably didn't game it.
risk of what?
there is refund policy
https://alexhost.com/faq/our-money-back-policy/
if the company is honest as you say then he can provide all evidence and say that doesn't match my needs then ask for full refund
My assumption is that they don't and that they very much identified the order at this point.
thank you for telling us the sky is blue @jsg
love you
And also they could have just said "order whenever you want, then once you're done testing, let us know the invoice ID and we'll refund it" really
Understood - I was talking 'generally' rather than specifically about Alexhost.
If a provider did not have a refund policy why would jsg take the risk of paying their own money just to make the review.
I agree with @ralf perhaps agreeing with a provider in advance that an 'anonymous' purchase will be made which will be refunded after testing is probably the better solution. Although I also agree with @emgh it is really down to 'trust' by both parties.
I'm quite confident that in particular this case the provider did not cheat. (a) it would have been very difficult, (b) the results do not at all indicate an especially good server, and (c) I didn't ask, they did contact me.
Now at this point I can't but offer an educated guess. Often when a provider contacts me they want "real numbers, hard facts" ( a quote from more than one such PM ), sometimes even mentioning that yabs creates an unrealistic, too positive impression, and that they prefer my benchmarking. Usually those requests aim for a not published review only for themselves (and offering in return e.g. one free year on the tested VPS).
While @alexhost did not ask for a "private" review the whole conversation felt very similar to what I've experienced with providers asking me because they need some feedback, identify weak spots or potential to improve. So it would be counterproductive for them to provide a "pimped up" server to me.
Btw, I often do pay for servers I want to benchmark myself out of my pocket.
As for emgh, I'll simply ignore his stubborn private crusade.
You actually didn't manage to do so, pathaps a sign of your lacking self control. You also didn't respond to any of my points in any way that disproves anything I said.