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.
Faster server with slower connection VS slower server with faster connection
Hi,
Many major providers these days offer decent network connection for their VPSes, but there are situations, when we have the dilemma I put in title. If you face such situation like: getting a server with 100Mbps connection which is faster CPU wise and cheaper than the one with 1Gpbs connection - which one would you pick?
Comments
depends what you have to do with that server...
I understand, that there could be different scenarios, but let's say server would be used for hosting website(s)?
depends what you have to do with those websites
Usually people do not need the connection speed they think they need. Unless you are running a file server with large files or you are getting a ton of traffic then I would go with a faster server.
I was just writing the following:
Usually people don't look for servers if they don't care much about how their websites will perform.
And I was leaning towards wider bandwidth.. What if there's a need to serve multiple pages of a few megabytes in size?
@vero If this is just for serving websites, a decent shared hosting with optionally, a CDN is more than enough. If it's truly high traffic, perhaps a bunch of cheap, geographically diverse VPSes routed to via GeoDNS.
The answer to the question depends on how „compute intensive“ your website/webapp. For example, bloated Wordpress setups (basically any Wordpress setup with a few addons installed I‘ve seen so far) usually drain heavily on the CPU when multiple users are connecting to the website concurrently. In that case the CPU might be limiting factor long before you reach the network links limit. However, if your use case mostly consists of distributing static files, such as hosting videos or operating a CDN, the network uplink might be the limiting factor (or eventually even disk I/O, but with SSDs thats less often an issue nowadays).
Looks like we have two votes for CPU power vs network so far..
What does it mean for you "slower connection" ?
and what does it mean "faster server" ?
Make some examples ..
100Mbps vs 1Gbps - look at original post. Speaking about CPU - 4 vcores vs 2cores, for a simple example.
I'll grab the faster network almost all the time. You can saturate it with pretty much anything these days
The one with most RAM. CPU is only secondary in 80+% of cases. network speed is rarely of any concern at all; 100 Mb/s are good enough for almost all private and small business usage.
Depends on the scenario - Is the stuff running on the server CPU-bound or network-bound?
More RAM without a question, agree. 100Mbps is rather kind of psychological barrier and for some it's impossible to overcome
They are usually bound together..
Not always.
If you're serving lots of files (for example, imagine something like a CDN edge node that just directly serves files) or storing backups, CPU doesn't matter as much - You want fast disk I/O and fast network. For backups, you even don't really need extremely fast disk I/O. For those use cases I'd pick the server with the better network connection.
If you're transcoding local video files or frequently compiling large projects like the Linux kernel, you'll be hammering the CPU but barely using any network traffic. For those use cases, I'd pick the server with the better CPU.
Let's have a look at LET and assume (completely oversized) that there are 1000 posts/day.
That would translate to one post about every one and a half minutes. So much for the write side. As for the read side there's caching (which boils down to RAM).
Let's assume there are 1000 requests per minute which is a bit over 15 per second. That's something even a not powerful server could easily handle (if properly set up and configured).
LET's home page seems to weigh about 3.5 MB. Times 25 (let's have some reserve) still less than 90 MB per second, so LET is an example of a site that really needs 1 Gb/s (but only because it's very fat at 3.5 MB).
If one's site has an average page weight of less than 1 MB and is a bit less prominent (frequently visited) than LET, 100 Mb/s will do fine and even a 2 vCores (max 4 vCores) VPS could handle it. RAM is the decisive resource that makes most sites fast.
I happen to run a perfect example, a quite well visited blog with 15 comments avg/day and a couple of 1000 unique visitors/day. I ran it on a VPS with 4 vCores and 4 GB for years and never came even close to 100 Mb/s. One day I found it a bit slow and doubled the memory to 8GB and since then it really flies even under occasional very heavy load.
Simple reason: Most even write heavy web sites have a read vs write ratio far beyond 100:1 (and usually even 1000:1 and higher) plus by far the most requests are for a few URLs/pages, hence RAM is the decisive element.
True. CPU in these cases doesn't matter much as long as it's not a complete trash.
These tasks don't even have to be performed on server, IMO.
Yes, definitely re kernel builds. For videos the problem/reason might be that uploading them still is a PITA for many (with normal DSL connections) so they understandably prefer to transcode them on the server.
BUT: transcoding rarely needs to be done at top speed.
Good example. Checked with similarweb - LET actually gets about 1400 pageviews per hour. So in theory it could live with 100Mbps as well
It practice traffic peaks also happen.
Kernel recompilation is not what many people are after.
I've done it once, in 1999.