New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I suppose it was a marketing stance to offer such dirty cheap servers, so that people carry on talking about it. And buying it for fun since it is so cheap. It does not really matter what to idle
Claims:
1) "1 MB/s IO" - Untrue
We have limits at 150 MB/s read and 150 MB/s write and 1000 IOPS read and 1000 IOPS write. We've set limits to guarantee steady and predictable performance for each VPS rather than letting each VPS YOLOing on the storage for benchmarks
2) "bad network" - Untrue
We have uncongested Tier-1 links. Please read https://massivegrid.com/blog/why-network-congestion-occurs-causes-and-identification/ - many people confuse the reasons of a slow network.
3) "instead of SSD" - Untrue
We only use datacenter grade SSDs on a HA triple replicated CEPH architecture for reliability.
4) "no reviews" - Untrue
Googling "MassiveGRID reviews" and they are on the 1st page including the hosting specific review website HostAdvice https://hostadvice.com/hosting-company/massivegrid-reviews/
Yep, highly likely. As I already said I do not even think that they did/do it for revenue but IMO mostly for (a) hell, let's at least cover the cost of all that equipment and (b) to gain visibility.
As quite a few here noted, before their promo here it was like "@massiveGrid???" Who's that, never heard of them" - but now it is "Yeah, right, the guys with super-cheap but reliable VPS, I know them".
Exactly that. Well, this is also an approach will generated around 1k posts in a few days, I was afraid they may beat Racknerd's thread but anyway...I decided to skip this offer straight-away but I think this place is a good one to post such an offer.
You see, I have put a 5 Tb/s IO limit on my old server. Problem is: that does not mean that it'll ever reach that limit...
I wouldn't call it great, but yes, it's not badly congested or otherwise crappy. For me it's "damn good enough" especially for the super-low price.
That's good to know but doesn't change the fact that disk IO is crappy.
But OK, you made your point and showed to us that there is not "no reviews" of you. After all, 1 != 0.
And hey, now you even can show one more review and one on a way more credible source than hostadvice. On LET. And it's not even negative, in fact I said - and still say - that, besides one caveat (and one bet "will it really hold and work for 4 years at the same conditions?") I think you offer an attractive deal and I actually like my little massiveGrid VPS.
As some people argued, doubted my statement that the disks are crappy and certainly not suited for databases, and asserted quite the contrary (e.g. "1000+ IOps") I looked at it again.
And I did that in the only way I find acceptable: I wrote a small benchmark to gather real world numbers.
Granted, a simple one, just one table with a simple structure: 6 integers (of different size, from 16 bits to 64 bits) plus one large-ish TEXT field of 512 characters.
Everything all data, all fields were fully randomized, the text field then put into a printable char form (with a 64 character set), so as to avoid any no matter how unlikely risk of caching.
That step (generating the data) was not timed, so the time data you get to see are from sqlite (3.x) execution only that is, creating the db and table, filling it in batches of 50 INSERTs which then were committed, and finally closing the DB. The whole "benchmark" was designed intentionally so as to mostly be dependent on disk performance (as opposed to processor or memory). The CPU intense part was the generation of the data and was not timed. The numbers I'll show are the SQLite DB part only.
The number of records that were inserted was quite modest. After all, the goal wasn't to stress test the servers. FYI the resulting DB was about 30 MB in size. That may sound shockingly small but again, (a) that's plenty enough to get a good impression, and (b) while small a bit over 50000 records of a bit less than 600 bytes each is not an unrealistic table for many small to mid size sites.
Here are the results:
Remarks/Notes:
"old box" is a VM on an old E5 v2 ("stone-age") dedi with a decent but not fast SSD.
the massiveGRID VM also has no storage drive.
the two other VMs were tested against their storage drive (usually spinning rust)
c1vhost actually has decent processor & memory performance - but the crappiest disks of all
The proof is in the pudding as the saying goes. So, what can we see in the 4 "puddings"?
Obviously the c1v VM is the slowest by far, but then, I did say so in my review. The VM on my stone-age dedi is not all all bad. I was a bit surprised but then the dedi is only lightly loaded and the VM can go full speed, well, as "full speed" as a stone-age machine can. I'm pleased by how well such an old box performs, albeit under somewhat favourable conditions.
host_c evidently has discovered some magic. Probably multi-level caching, very good RAID hw with a fast and certainly not small cache, etc. Whatever his secret sauce is, it clearly blows many if not most SSDs out of the water. (a bit) more than 4x the performance of a decent SSD, grok that! On a fucking spinning rust storage drive! Unbelievable. Maybe now you understand better why I recommend him whenever I see "storage" mentioned.
Finally the "star" of this benchmark, albeit a rather dim star, the massiveGRID disk. While I wouldn't call its performance abysmal - that tag goes to the c1v storage VM - what I had said was clearly proven. It's a crappy disk and certainly not fit for DB jobs.
QED.
Epilog: I'm thinking about running that benchmark (with exactly the same parameters and data) again but against a RAMdisk. Why? To take the disks out of the equation and to verify and demonstrate that this benchmark really was hardly influenced by the CPU or memory.
And then put the results next to each other.
OTOH the data (to be INSERTed into the DB) were preloaded and fully in memory anyway already and timing only started after loading them.
I know why it hurts to some poeple
, MassiveGrid are just a better version of RackNerd but more cheaper 
BTW i ordered their 1GB server and im happy with that. Waiting for their BF deal a vps for 10 years for $10 ?? 
I clearly said that I think that that massiveGrid promo VPS IMO is a good deal and that I like it - but that one should not use it for any DB (or other disk heavy) tasks.
And that is what my new benchmark confirmed. Simple as that. As long as the disk is used only lightly it's a decent VPS and I'm happy with mine too.
😁😁😁😁😁👌👌🤣🤣🤣
The truth is that I bought this one and I have done several more tests with MariaDB and MySQL and the response has been quite good and I have a database that weighs 3GB and the response has been fast. I have 10 to 12 thousand visitors a day, apart from that the response is very fast.
@jsg thanks for that test and numbers. You attack the 1k iops statement, which by the way is only the limit on small blocks like 4k while on larger the throughput limit will automatically bring down the possible IOps even more. (bandwidth/blocksize=iops).
Could you explain a bit more how you derive IOps performance from your test?
Generally curious, as I don't know how sql-lite actually accesses the disk. Is there a commit size, cache involved etc?
Under the (probably wrong) assumption that each row is written individually it would make about 50k IO operations in about 15 seconds. That obviously would be over 3k iops, which we know is not possible...
On the other hand if each insert is a single commit you'd be in a range of >512k blocksize, where it is also obvious that the maximum achievable iops is something like 150 (assuming the 150MB/s bandwidth limit ln these VMs). Yet agreeable in that case the 50 writes should not need 15 seconds but also your other, much faster setups do need more time.
Hence the conclusion can only be that the real amount of IO operations thar sql lite creates has to be known to make a real decision on whether the 1k iops statement can be real or not.
TL;DR; your test is a good one because real and you gave it a good thought regarding the sizes etc. But I think it specifically does not say anything about IOps as such unless more clarified about sql-lites behaviour.
The limit is 1000 iops as you can see in the publicly accessible proxmox gui
The question then becomes: does it actually reach that limit consistently? In my testing it does just about meet it, but less comfortably now than when I first received the server
Your SQLite benchmark likely boils down to testing syncing to disk and filesystem more than actual performance. Anything with defeated syncing or a writeback cache in memory (such as hardware raid with BBU) will smoke a standard SSD setup for small synced writes
Once you see any VPS outperforming a normal SSD in a test like that it should ring alarm bells for data safety (as effectively your entire server is running under ‘eatmydata’), unless you can say for certain they are using battery backed hardware raid
No, I do not attack the 1k IOps statement, let alone the person behind it. That statement just happened to be the trigger for me to design and build another benchmark specifically to verify my statement that that massiveGrid VM has a crappy disk and is not fit for DB or other disk heavy tasks.
The 1k IOps was not what I tried to show true or false, it only was the trigger.
I thought I had laid that out but it seems I failed, so, sorry, I'll try again:
First, again, I wasn't after getting IOps numbers. Those of course are a factor but I already had those from my original benchmark; what I looked for was simply DB performance.
To put it simple and straight: No tricks were used, any sort of smart caching (by OS or disk controller or whatever) was aggressively broken by only using fully random data that is, everything, every field of every record was random data (besides obviously the auto-created (by SQLite) row id), so any caching that was possible was only "dumb" caching and even that was rather limited due to the relatively small block size of write requests (roughly 30 KB).
The way I did it wrt SQLite was 50 INSERTs per transaction (COMMIT) and that a bit over a thousand times. My timing began only right before the first INSERT and ended right after the last COMMIT. The whole preparation (like generating random data in a form that SQLite could digest, i.e. ASCII (limited to 64 printable alnums), etc) was not timed because I didn't aim at the processor or memory but in fact tried to keep anything but the disk performance as irrelevant as possible.
In case you want to do calculations, "select COUNT() from lettest;" gives 51563 and the DB file is 30257152 bytes, and the average record is a bit under 600 bytes (just dividing the two numbers gives about 586 but that's wrong because of the SQLite internal housekeeping stuff). So the benchmark does a bit over 50000 writes of about 30KB each. But again, (in this benchmark) I didn't hunt IOps numbers, I hunted DB performance with a realistic scenario.
Edit: there should be an asterisk parameter in 'COUNT()' but unfortunately this forum's software mistakes that as a format (italic) command.
No, in my publicly available benchmarking it does not. And pardon me but a limit (visible in the proxmox GUI) is just a maximum and says little to nothing about actual performance.
Whatever it may boil down to, it is a benchmark that clearly shows what a user can really expect from that VPS's disk when using it for a database. Because my test actually is a DB application, albeit a carefully designed one that is precisely timed.
That's, pardon me, BS! As long as the controller has batteries, and the server has a UPS available and dual PSUs everything is fine. The "eat my data" allegation only becomes relevant if a provider has no UPS and no batteries on the controller and, to top it off only a single PSU (or two but fed from the same line).
Whatever I made no statements on that with any of the providers in this test because I didn't want to wildly speculate.
I think that part of the problem with perceived disk I/O speeds vs what you think they are is a Proxmox issue. I can verify all of your claims by looking at the hard disk line under hardware in Proxmox. It has iops_rd=1000, iops_wr=1000, mbps_rd=400, mbps_wr=150. Let's ignore iops and read speeds for right now. Regardless of the blocksize I use (512, 1k, 2k, 4k) I get very consistent write speeds of 130Mbps. Yes that is slightly below the 150 you have set but that's likely just overhead. Now the problem is that the Proxmox docs state:
mbps_wr=
Maximum write speed in megabytes per second.
And that is your claim, that the limit is 150MBytes per second (which would be pretty decent). However, I believe the Proxmox docs might be wrong and that is 150Mbits per second instead which lines up with the benchmark results I am getting over and over on almost every single test. 150Mbits/sec is just 18.75Mbytes/sec and with my 130Mbits/sec that's just 16Mbytes/sec. Just spin up a VM and run some simple dd tests and you will see what I mean. It is super consistent which to me means that the Proxmox threshold limit is working just not at the speed you think it is supposed to be working at.
This $23 Paid for 4 Years worth every penny.
Im hosting a Site here with medium traffic and a medium MySQL db without issues.
Please post yabs results in the yabs thread, not here. This thread here is about realistic results users can expect.
MassiveGrid has been kind enough to tweak some settings to try and get to the bottom of the disk performance issues.
You cannot simply ignore iops, because they are tied to bandwidth exactly by the blocksize!
Of course you do. The largest of your blocksizes here is 4k. If you are limited to 1000 IOps this simply means you can write a maximum of 1000 blocks to the disk in one second. 1000*4k is 4 Megabyte. Per second. Multiplied by 8 brings you to 32Mbit per second.
So to achieve 130 Mbits you already need larger blocks...
No, it is for sure Megabyte per second.
you simply cannot ignore the IO limit and blocksizes.
Totally agreed. Run a dd with bs=1M and bs=512k and so on. That is exactly why yabs runs the fio disk test with four different blocksizes. The small ones will help determining the IOps limit and on the large blocksize you will find the max bandwidth.
Of course that is no real world performance test, but it helps a lot to see artificial limits.
Can you post realistic results for Racknerd 10k vps with 1 node please ?
Yes, thanks I nearly thought we wouldn't get to that.
So 50000 writes of random data directly to the disk in 15 seconds, no cache involved?
Which of course is good, as I already said.
And yet, while you were not hunting IOps you just confirmed that your benchmark achieved 3333 IOps on this VM.
100% agree.
Storage is tricky. The 2 biggest factors in performance is IOPS and Throughput (MB/s) and when we benchmark, we need to be able to get the results for at least the above 2 factors.
@Falzo analyzed it very well.
Depending on the performance we have then we might be able to adjust our real world workloads. For example, databases, web servers, have memory caching features that we can tune in the configuration (after all big DBs with lots of transactions existed and performed in the past even with spinning drives of 100-200 IOPS).
By tuning our web servers and DBs we can utilize the underlying resources the best way possible.
Thank you for working with me to test different settings.
No, because I do not have a VPS from them. But if @dustinc provides me with access to one for a couple of days I'll be happy to benchmark it.
Nope, that's not what I said nor what this benchmark could achieve. No smart caching is what I tried to exclude as best I could (by not repeating patterns in data).
One can look at it this way, but (a) for an IOps test the total size written is way too small, it actually fits in an even relatively small controller or even disk cache, and (b) what I confirmed actually was that that (massiveGrid VPS) disk was quite slow and even a decent SSD on a stone-age VPS outperformed it as did a storage spinning rust disk. Only 1 VPS with a truly abysmally slow (spinning rust) disk was slower (c1v).
Sorry, but if doing the same database job on 3 other VPS is faster on 2 of them than the massiveGrid VPS which outperforms only one, and known to be a really, really crappy storage VPS, that clearly shows that the massiveGrid VPS is not fit for DB or other disk-heavy jobs - just as I had said.
Go on chasing IOps numbers, have fun, but I care about what users can expect in real world usage. Just like I don't care about funny iperf BS marketing numbers but about real world http performance.
Btw and again: my point wasn't and isn't to trash talk this or that providers product. I clearly said and still think that all in all I like my small massiveGrid VPS and think that it's a good deal - as long as it's not used for disk-heavy jobs. The price is exceptionally low and one gets a product that is not bad. So, nothing to complain, just a well-based caveat note.
BS! His "3300 IOps" - at a block size of 30KB and not even 4 KB! - clearly contradict your 1000 IOps limit. So, what's it then, one of you must be off. Plus he almost obsessively focused on IOps and seemed to not be interested in anything else. And that in the context of a database benchmark that explicitely (a) was focused on "what performance can a customer expect with a database running on your product?" and not IOps, and (b) clearly showed that even a VM on a stone-age server with a decent but not fast SSD outperformed your VPS as did a, granted excellent, storage VPS using its spinning rust drive.
Well, go ahead, don't just talk, DO IT!
As I already said multiple times I actually do like your promo VPS and think it's a great deal. I'll be glad to benchmark both its general disk performance and its DB performance again when you're done optimizing its crappy (but by no means abysmal) disk performance!
@jsg sorry to say, but I am not obsessed with IOps, but I am with people not even trying to understand the relationship between all three things for that matter - iops, blocksize, bandwidth.
That is why your benchmark is a good approach with not just a fixed size. And of course comparing it to other VMs total makes sense.
Yet as you yourself point out the caching layer under the layer of the VM plays a role and here is, where it gets interesting. For your small overall test size a heavily cached harddisk raid can outperform the IO limited VM easily. Simply because the cache allows a burst that the hard cap will not.
In real life would your benchmark reflect sustained load over hours or just a burst?
And by the way, I did not say the VM achieves 3300 iops. Thats simply not possible because of the limit.
I said your benchmark did achieve that according to the base numbers you gave for calculation.
Thanks anyway, I still think your approach is the right one, yet for a benchmark it's not wide spread enough. the result are not really comparable to anything other then your descriptions of what you offered for comparison.
I appreciate your reasonable answer. And I agree, my little DB benchmark was not what I would use if I wanted to seriously benchmark some system for serious DB use say, of a company client (or even myself).
But you see, that was not what I set out to do - and I clearly said so. What I aimed for was a quick test to find out whether my statement about that disk (not being fit for DB jobs) based on my original full benchmark was correct or not.
Btw. the fact that my dataset is quite small actually is advantageous for @MassiveGRID because even a small (dumb) cache with very high likelihood can handle it. With a larger dataset the results probably would be worse for them.
But hey, I made my software in such a way that I can easily have it create and work with a significantly larger dataset. How about 10 or 25 times the size? Just let me know if you'd like me to do that and present the results here.
Thank you, @jsg
These benchmark numbers speak for themselves.
I have a VPS from @racknerd
2 vCore / 2 GB
I can run benchmark tests for MS SQL Server 2022 database server.
Tests —
@MassiveGRID
if you can provide me a trial vps for 3 days, I can run same benchmark tests on your VPS
Yes, if it is not too much to ask - both please.
You can leave out the c1v box though ;-)
Thanks but I don't think that a benchmark on a Unix system using one SQL database and a benchmark on a completely different OS using a completely different SQL database and then somehow comparing them does make a whole lot of sense.
But thanks for your kind offer.
But as I am not one of the @dustinc haters, I think there's a realistic chance to get access to a 1 vCore 2 GB VPS for a few days ...
SQL Server database will be installed on both Linux based VPS with exact same configuration.
I am running Linux based OS on racknerd vps.