Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.

pdellepiane's avatar

Best Server

We are creating a web service that is going to be used by 100k + users in the first year and then it will be growing a lot (well, thats what we estimated).

We are currently using AWS and we don't know yet if its the best option. We are using Laravel (soon Lumen) and we have a socket system and also using GCM**. Our web services are going to be used by Android, iOS and web.

Which of this is our best option for a server:

  • AWS
  • Google Cloud
  • Azure
  • Digital Ocean

We are looking for fast response and cheap.

Thanks for your help!

** We are mixing sockets + GCM. When the app is working on background, we use GCM, when not, we use sockets.

0 likes
6 replies
christopher's avatar

Why isnt AWS the best option? In my opinion AWS is the best option for scalable hosting.

100k users per year is not that big. 100k users would make around 274 Users per Day, so thats really scant.

Such a cloud plattform only pays out if you have thousands of users per day.

If you have a little VPS Server with a few gigs of ram the server can handle 1k users per day minimum. Of course it all depends on the hardware and configuration.

But with such a Cloud Plattform you pay a lot more then for a normal VPS in terms of the hardware, because of course you cant compare AWS with a normal virtual private server or digitalocean. They are completely different services.

Of course if it really comes to real scalability with tens of thousands of users per day AWS is top notch

1 like
nickywest's avatar

I don't get how @christopher is throwing out numbers that a server can handle without knowing workloads and use cases first. I have use cases where 1 user can monopolize a monster of a machine, and I have use cases where a very slim VM can handle hundreds of thousands of users per day. It completely depends on what you're doing.

@pdellepiane, any of those options are good, but you'll want to engineer specifically for the one you choose. The workflows on those services are all different. DO is probably the more complex one, in that you have to do more yourself (using their API to bring droplets up and down, and building out the various component droplet images), where as with Azure, Google Cloud, and AWS you get more dynamic scaling tools and specific services out of the box (compute, storage, db, load-balancing, etc are all separate offerings), but you you have to learn how to use them all (it's different than just using VMs).

If you intend to do all VMs and roll your own components I'd recommend DO. The price is great and the service is good. It's more work to setup and manage though, since you're managing each component (and it's scaling).

1 like
christopher's avatar

@nickwest we are talking about web applications right? So i assume its not about a high complex math task which the server has to handle and where you would need a "super computer" to solve the tasks.

I assume its about a "normal" website like laracasts or any other website/application onlineshop what ever. So yes you can approximately estimate how much users can handle a specific server. But of course - approximately.

I think we all can agree that a VM with 1 CPU and 512MB of RAM cant handle 50.000 active Users per day - The complete thing would extremly slow down.

nickywest's avatar

@christopher He's making a web service for mobile devices. So that could mean data collection, a game, a chat app, anything. It could be an active thing (user interacting) or a passive thing (background process hitting the web service). If it's passive, it could be doing it every second for 100k users who have the app installed. Realistically, it'll probably be polling every few minutes at most, but at 5 min intervals that's still 28.8M requests per day. Or maybe it's only while interacting with the app, so a user submits something to OP's web service after clicking a button. with 100k users, maybe 20% interact with it once per day, that's still 20k requests per day.

Users per day != requests or load at all. If you run Apache and serve static content to 99% of users and only have to load pages for 1% of users you can easily handle 50k users per day on 512MB of memory and 1 cpu. Apache is great at serving static content and if your app allows for serving static content most of the time, you can get by with a really slim server.

There's just so many possibilities. Without knowing workload and use cases you can't say anything about what kind of resources someone is going to need.

Take for example a simple application where you expect 1,000 people work on and submit an essay, auto-save as they work on them, check those against a plagiarism service on submit, email them a success message. But you have a deadline of 5:00p precisely. Now you've created a workload where you're going to see a giant spike within the last hour before the submission deadline (realistically, this works out to 90% for me and it's all within the last 15 minutes). Now you offload the plagiarism detection and email to a queue, but you still have 900 posts of large essays within 15 minutes, which works out to 1 per second. The real trick is the auto-save. You have 900 people working on essays simultaneously, and as they pause typing, it's making an ajax request to auto-save. When you hit 250 requests per second you start to wonder if you accurately predicted that 1000 users means you can use a small server.

3 likes

Please or to participate in this conversation.