How can I estimate how many page views per second or in parallel an instance like t2.micro can handle? I know this varies depending on database queries, template processing and such, but I need some conservative estimates or real world examples just for a point of reference.
-
1This question is kind of meaningless, and you've managed to exactly point out why. Also, do you want to use Cloudfront? No? How much of the web page is a script or not? It's completely meaningless tbh, sadly! – Henry Jul 09 '17 at 17:35
-
You say you know it depends, yet you're asking for an answer. If you're serving static pages or doing some heavy queries, the answer is going to vastly differ. The best way to test it is to deploy your app or a mockup of what your app will be doing and stress-test the endpoint to see how it performs. – Marko Gresak Jul 09 '17 at 17:35
-
I know it depends, the problem is that I need to produce some estimates up front (no code yet) and have no experience with this, so I ask here for some guidance from people who already have expertise. I dont expect you to pull a number out your ass. – ArekBulski Jul 09 '17 at 17:41
-
There are simply too many variables to even begin to come up with a meaningful answer. Even if you had examples or points of reference, the usefulness of these numbers would be illusory. Put your application on one and benchmark it, paying particular attention to the CPU Credit Balance metric over time. Once the balance is depleted, you can then observe how much traffic the machine can sustain on a continuous (non-burst) basis. Before that, you're only observing peak/burst capability. – Michael - sqlbot Jul 09 '17 at 17:42
1 Answers
You're going to have issues if you try and apply a typical VPS type thought process to AWS. One of the strengths of AWS is that you have elasticity. Put up some instances, then add more when demand increases. Auto Scaling Groups mixed with an Elastic Load Balancer helps greatly with automatically dealing with demand (though it's not going to handle unexpected spike traffic very well, you'll just have to have a lot of standby instances ready if you want to deal with that).
One reason why you don't want to have t1.micros directly serving up requests is because slow clients can take up sockets that could be used to connect to the database. That's why you let ELB handle the clients instead so you don't have to deal with that. Also how many clients you can handle will be very much based on the number of available sockets, available resources, what type of web server you have installed, etc. etc.
If you're serving up static files then just use S3, potentially mixed with CloudFront to deal with that. For dealing with simple API calls that do CRUD operations on a database just use Lambda Functions with API Gateway. Since both Lambda and API Gateway will scale up with demand you won't really have to worry about the page views issue as much.
You're simply going to have an extremely difficult time finding a direct answer to your question just due to the way AWS works and how folks utilize it.

- 1,409
- 8
- 10
-
Its not static content, so S3 and CDN are not enough. I was thinking about lambdas vs ec2 instance, which would be better for handing http traffic, but lambdas are stateless therefore cannot cache anything right? – ArekBulski Jul 09 '17 at 22:40
-
@ArekBulski Well, Lambda can interface with other services if you really need that. DynamoDB, Elasticache, RDS, S3 are examples of places you can store things for pulling up later. It all really depends on what kind of state you're expecting. – Chris White Jul 10 '17 at 16:15