Ultimate Web Server, or not?

Targets Web
1

This is entirely theoretical, but if I took an 18-CPU iMac Pro (or equivalent Mac Pro, Windows or Linux box) and placed 18 copies of my average-workload WebApp as standalone, using load balancing techniques described on this forum, and placed it behind a dedicated leased fibre line (100-300 MB up and down), should it work OK?

Or will I hit other performance issues (RAM, bandwidth, SSD speed, etc) before I even started taxing the 18 cores. If each WebApp instance can support ~10 people, could I support ~180 simultaneous users on this machine?

2

Sounds right.
But I would expect that you can even run more copies of the web app.

3

So, again theoretically, how many copies of the same WebApp could we reasonably run on a per CPU basis — 2, 4, 8? ie could my iMac Pro run 36 or 72 or 144 versions of the WebApp and support ~400-600 WebApp Sessions?

4

Do I know what your web app does?
Most time it’s sitting idle, so even 2 per core may work.

Problem is when people do heavy work. e.g. when they press a button to generate a report as PDF and the web app is blocked for a few seconds for all due to limited yielding in multithreading.

You may need to measure and add more instances till you notice an impact on performance.

5

Your case seems perfect for a cloud app. You buid an image and rise new instances as needed.

6

Rick, I agree. I have many WebApps that I want to offer at a small fee. My fear is their success!

Why? Because I will be charged thousands of dollars per month to host them at the level of 500 users (lots of dedicated CPU, RAM and bandwidth). I was theorising whether, if getting a dedicated fibre line (~$50-200 pm) or CoLocate a server, I could grow the number of users without running out of money!

Buying a large PC/Mac is a one-off cost, not a monthly fee, so could be cheaper in the long run. But I don’t want to consider it as an option if there are good technical limitations that I am not aware of.

My current default plan is to use ServerWarp, Xojo Cloud or Amazon EC2 VMs, but and I am not sure if they could scale to hundreds of users.

Again, this is all theoretical.

7

Your business model must have, or anticipation of users costs passing them to your prices (fixed prices), or having dynamic prices based on users consumption of resources (invoices). Your EULA must protect you of miscarriage of the business due to lack of enough users to make it profitable and possible service discontinuation in case of that. Google Cloud have great prices, but you need to design your architecture to get the best price per/month from it (Like deciding to use small instances handling 10 users, instead of larger one trying to handle 100 (not a Xojo, one thread, forte))

8

Google Cloud can scale to thousands of users, so does AWS. But they need that you have designed correctly your application and virtual architecture.

9

If it were me, I’d probably spin up a VM on my server and assign it say 4G of ram and 2 CPU cores and install docker. Then I’d set up a docker instance and stress test it. Then I’d set up a second instance and load balance them and test again. After that I’d hopefully have an idea of what kind of load I could handle and how much I might have to ramp up if I meet with roaring success.

10

[quote=437468:@David Cox]This is entirely theoretical, but if I took an 18-CPU iMac Pro (or equivalent Mac Pro, Windows or Linux box) and placed 18 copies of my average-workload WebApp as standalone, using load balancing techniques described on this forum, and placed it behind a dedicated leased fibre line (100-300 MB up and down), should it work OK?

Or will I hit other performance issues (RAM, bandwidth, SSD speed, etc) before I even started taxing the 18 cores. If each WebApp instance can support ~10 people, could I support ~180 simultaneous users on this machine?[/quote]

As Christian pointed out, this depends entirely on what your app is doing. There are no easy answers or estimates here.

I will say that in my personal experience, in general, cores are outstripping the rest of the motherboard. I continue to run into examples where a company jumped on the VPS bandwagon, bought one big server with a massive number of cores (or leased a bunch of cloud VPS instaces), then wondered why their SQL database ran unbearably slow. RAM is shared along with all its latency issues. The main bus is shared. Per processor the L2/L3 caches are shared. There may be multiple NICs but as a group they are shared, and the bus they connect to is shared. And SSDs have amazing IOPS…but they’re still shared over a shared bus. So right off the bat I would challenge a client who said “we need to buy 18 core servers!” because maybe what they really need are 4x4 core servers.

Having said that: if you’re trying to discover if Xojo can, in the stated configuration, take advantage of 18 cores I’ll answer this way: I’m certain I could write a Xojo app that would saturate the NICs, the SSDs, and possibly even main memory when run across 18 cores. Xojo is not your limitation here if you can work around the lack of preemptive threading via multiple processes.

11

Could probably run much more than 18 instances. CPU is almost never the bottleneck.

12

Scaling is real beast of problem, deal with it as you grow.
Most aproachs deal with it separating different layers in your solution, your application is just one layer.

Probably the first layers (user perspective) is load balancing, there are several ways to do it, to use Xojo Web framework you have to use session stickiness. Why ? Because with multiple copies of the same app, session cookies are not shared. You could roll your own shared cookie solution, basiclly save the cookies to database and accessit by all copies, but really is a project on it’s own.

Next is securing the conection, TLS (from Https), this is cpu heavy and should be handle separatly. Probably good ideia to handle it on the same machine (vm) thats doing load-balancing, Nginx or Haproxy can handle it.

Next layer is the application itself, do some profilling to detect which functions/features are most used and improve performance (code refractoring). Logs are your friend, log everything to determine comun usage profile and optimize targeting the usage profile. If you application is healy used some days of the week or month, think about scalling (adding vm or copies of your app) just for that period of time.

Propabilly the next layer is the database, most commun in web apps, scalling databases is not your run of mill activity. You can grow database cluster but is really advance/specific topic. Easier is just get bigger machine to handle the database. Most web apps stress network conections and memory, databases stress I/O disk access. Again knowing your app usage can help, sizing data and queries helps to optimize workloads and response time.

Web apps are all about responsiviness to user interactions, nothing is more frustrating than clicking a button and wait for minutes.
Improving is a continuos job, one feature at a time.

One last word, lost of engenieers have work on this problem. Virtual machines and containers are basic building blocks of todays web architrecture, don’t try to learn everything to do it your self. Just luch the product/app based in cloud offer (maybe xojo cloud) and learn users usage patterns and data consuption, then use this knowledge to scale the app to more users. Early optimization is evil in pure form, costs to much time and money.