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
Depends on your usage, but you got 4 ipv4 if you bought 4 smaller VPS separately, also more bandwidth. I, myself would pick one CAX11 tbh, 8v 16g is overkilling for me.
How about the performance in comparison? Is
1+1=2? or1+1<2?It really depends on what your application is doing. If you've got a single threaded application then having multiple machines will perform better as you wouldn't be using all of the cores you have available. Unless you run multiple instances of the same application on a single machine.
I'm not sure how hetzner works but if they limit the iops per vm and your application utilises the disk a lot, then you may be better off having multiple machines. However, this may come with the trade off of having to shard or replicate databases etc.
Having multiple machines may make your stack more resilient, if you configure things properly, but then you'd have to add in load balancers and all sorts of additional complexity.
You're probably best off sticking with one large machine until you reach the point that you need to scale, for certain things scaling horizontally is better, for things like relational databases it's sometimes easier to scale vertically (this is what stack overflow do).
You should focus on utilising caching as much as possible and ensuring your application is optimised. Get proper metrics in place (I like using grafana + icinga, telegraf, whatever) so you can see the performance characteristics of your stack. Blindly picking things or asking people without them knowing your stack makes it super hard to give a proper answer.
It's worth reading up on the pros and cons of horizontal vs vertical scaling. But ultimately, keep things simple to begin with and change your architecture as your requirements change.
Exactly what i thought. People often too much over complicate things. I thing to start with OP need single machine probably 2vCPU and 4GB ram. But again it all depends on what is the purpose. But definitely a load balancer with multiple instance is simply an overkill same is the case of DB sharding, all this will add layer of complexities in starting phase.
Always makes me think of blog posts like this:
40 million hits a day in WordPress using a $10 vps -
https://reviewsignal.com/blog/2014/06/25/40-million-hits-a-day-on-wordpress-using-a-10-vps/
That was a while ago now. You could probably do more than 40 million.
How does the bandwidth work on these Hetzner cloud instances? The limit is 20TB per month, but if it's billed hourly, then what happens?
If you realise that one cloud server is close to the 20TB limit and don't want to pay 25% of the original price for each extra 1TB, can you just spawn up a new one and shut down the old one? Or do you have to be tricky and keep the old one running and just not doing anything? Or something else?
And what happens if you just have an instance for a day? Does it get 0.6ish TB? If so, what happens if you go over that but not over the 20TB for the month?
Thank you very much! @bgerard
Benefiting us greatly! indeed.
Yes, that's my use case.
This will work and you'll be able to scale nicely with this architecture. However, for simplicity I would run the application server, Web server and database on one machine to begin with. If you then see that the database is taking up lots of resources, then consider moving it onto its own machine.
You could use something like nginx or caddy to be your Web server and also a reverse proxy to your application server. Is this some sort of headless WordPress setup?
@EthanZou you're compaing horizontal scaling (more servers) and vertical scaling (bigger server).
Vertical scaling is better because:
But there is a big catch, vertical scaling has hard limit. Once you get best CPU (like Ryzen 9 7950X), max RAM (128GB in case of Ryzen) then you cannot scale anymore.
This is where horizontal scaling comes in, there is no limit. You can have 1000vCPU and 10TB RAM if you want.
But with that you get major inefficiency.
If you have one VPS with 8GB ram and your usage is like: 1GB for OS, 2GB for Redis, 1GB for PHP+Nginx then you use just 50% of RAM.
If you want to replace it with 4x VPS with 2GB of RAM then if OS is taking 1GB on each VPS you have just 1GB per VPS for another things. You can use one server for PHP+Nginx, but you cannot put Redis anywhere. So with 8GB RAM you used just half of RAM, with 4x 2GB you are already out if RAM.
Horizontal scaling requires you to rearchitect and if you won't do it the best then youre losing money because of inefficiency and you have slower app because of network latencies.
So in conclusion: always get big VPS instead of couple smaller ones. Think about more smaller servers only if you can split load between them or one VPS/dedi just isn't enough.
Not all the time. It honestly depends on what you're running. A single instance of a single threaded application, no performance boost. If your code is not performant, throwing more resources at it may also not yield a performance boost.
Vertical scaling is simpler but not always the best route to go. Especially if you want to scale elastically.
It's complete opposite. Vertical scaling is ONLY way to get performance boost.
He is looking at ARM, he can get faster Zen2, even faster Zen3 or Zen4... this is essentially vertical scaling and as I wrote "Once you get best CPU (like Ryzen 9 7950X) then you cannot scale anymore.".
Only if he gets best CPU then its not possible to get performance boost.
If we instead of comparing CPU architectures and compare at 2vCPU vs 8vCPU on same architecture we still end up with minimal performance boost.
PHPBench (single threaded) on Hetzner:
CPX11 639535
CPX41 653525
It's nothing big, but its better to have one CPX41 than couple CPX11's for single threaded app that doesn't run in parallel. And that's just PHPBench on fresh instances. If you have ANY cpu load from MariaDB/nginx/whatever then difference can be >10%, because of fighting for CPU resources - with more threads you wont this effect.
You're right yeah, if the speed of an individual core is better then you'll get a performance boost. But jumping from a ryzen cpu to an epyc or xeon may actually reduce your performance even though you've kinda scaled up. Even then, if you're not cpu bound, you'd get no performance boost.
As I mentioned above, there's too many nuances to all of this for anyone to give a solid definitive answer. But ultimately the answer for OP remains the same, get one server!
NICE!
Many thanks for your guide! Both of you! @bgerard @AXYZE
So,
Correct?
In both cases you should get bigger server first, because with high RAM you can cache a big chunk of DB.
For databases its quite common to get older dedicated server, even 10 years old but with 192GB+ RAM. If you can fit everything in RAM then it will outperform everything else.
Use multiple servers if you hit limits of one server or need presence in multiple regions.
I would say: for application server get big server
for small cache servers around the world get small VPSes, as they will do near zero calculations, only cache responses from big servers + you can connect another small cache server in one minute to deal with big load.
If you want to use multiple servers for DB then you have native tools, especially SQL databases excel in that.
For MySQL/PostgreSQL search for "sharding", "read replicas".
Yeah scaling databases horizontally is much harder than scaling applications horizontally. Got as vertical as you can on the db. I've found scaling nosql dbs horizontally is far easier than scaling relational dbs.
For application level, it just depends what you're doing. I wouldn't say there's a right or wrong. For your standard sort of CRUD applications I find I tend to be blocked by IO or waiting on upstream or waiting on the db. So it doesn't matter too much, unless you're super calculation heavy.
For large event driven systems I tend to lean towards horizontal scaling of lots of smaller processes, then it's easier to scale up and down based on demand. Why worry about multithreading when you can just scale out your processes and let the orchestrator worry about it
(obviously this doesn't work for everything, depends what language/runtime you're using, how much you care about compute costs, the type of work you're doing etc etc)
Is RAM much more important than iops for DB like mysql?
Just for cpu & ram, not iops?
Depends what you're doing. If you're doing lots of reads you'd want to take advantage of in memory caching, the speed of the memory probably doesn't matter too much but you'd want enough memory to fit a good chunk or all of your working set.
If you're doing lots of writes, you'll want make sure that your system is configured properly so that the maximum number of file handles is high enough that the kernel doesn't stop allocating and things slow down. You should monitor cpu io wait to figure out if you're being limited by the disk, if you find the cpu is waiting on the disk a lot, then you may need to look into better disks, ensuring your queries are optimised etc.
Just today I had an issue where a database crumbled under load because certain queries were not hitting the index, causing lots of rows to be scanned, this put a load of pressure on the disk. Adding an index removed the need for a scan and performance increased. However, adding indexes to a database can hurt write performance, adding indexes to a database may also increase IO wait as the database may not read ahead. So if you have a small dataset, you may be quicker without them. In my case, there's a few hundred million rows so you definitely need indexes.
Nvmes will be perfect for running dbs, you just need to see if the provider limits iops based on vm size etc. I'd try and avoid providers who keep the storage separate from the compute nodes, in my experience it impacts performance once you search a certain point. I've had problems with ceph and dell vmax in the past, but I imagine you're unlikely to run into these issues.
Realistically unless you're dealing with millions upon millions of rows and hundreds if not thousands of queries a second, most of this doesn't matter all that much. You'd can run a web server, application and database on a small 2 core, 4gb ram, ssd vps and serve loads of users. Take advantage of caching static content with something like cloudflare and you'll reduce the load on your machine even more.
That's amazing!
Thanks for your valuable suggestions and It would be very helpful to all LETers like me.