Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
Customer has provisioned following for AWS RDS MariaDB instance:
Instance type: db.m5.large, vCPUs: 2, RAM: 8 GB, Multi AZ: No, Replication: No, Storage: 100 GB, Type: General purpose SSD
We are not sure what is the basis for provisioning the instance. Questions are:
What all factors should be considered to do capacity planning?
Is this a typical production grade database configuration?
Since
Customer has provisioned
we should account for customer's opinion and consider the factors which let them arrive to this plan, however there are factors which can help you in capacity planning i.e
If the transaction size static or dynamic.
If it is dynamic what could be the maximum transaction size.
What is the amount of network bandwidth each transaction is going to consume.
Will the number of transaction grow over the time ( it is suppose to grow anyways)
About production grade database configuration is anyways subjective question and can be debated however a basic architecture which is production grade looks like below -
Aws Pricing calculator is a good place to start with for most of the factors which should be considered.
Build the system on your laptop. If it scales well enough there, get an RDS of similar specs.
If it clearly does not scale well enough, get an RDS of the size up. Then work on optimizing things.
In some situations, you may have a slow query that just needs a better index. Keep in mind that "throwing hardware at a problem" is rarely optimal.
It is impossible to answer this question without knowing the exact specifics of the workload. However, it is unusual to have only 8GB of RAM for a 100GB database size. This puts you, optimistically, at about 5% ratio between buffer pool (cache) and data size, so unless the amount of hot data is surprisingly small in the specific workload that is intended, you will probably want at least double that amount of memory.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
I am new to AWS and was going through the fundamental course where EC2 types were explained.
It was mentioned that for the high performance database use cases, memory optimised AWS EC2 instance should be used.
Why storage optimised EC2 is not recommended to be used for this use-case as storage optimised focuses on IOPS?
Database queries are processed in memory so the more data you can fit in the memory the fast the query can be processed because there will be fewer reads from disk. Further, many databases can hold frequently used data in memory caches allowing some queries to be completely answered without disk reads.
Instances with faster disks will also help when operations can not be performed in memory alone.
The general rule of thumb is that a database will perform better with faster throughput and memory throughput is faster than disk throughput but both can help.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 2 years ago.
Improve this question
I have built my machine learning model and now as a next step I wish to make it publicly available. The plan is:
To build the UI by using Streamlit.
To package the application using Docker image.
To deploy the Docker image into the Google Cloud Run environment.
To start the Docker container in Google Cloud Run environment.
But the problem is that I cannot estimate what will be the costs when starting and running the container in Google Cloud Run (I'm still a beginner). How to estimate the worst-case scenario, i.e. what could be the maximum cost that it should generate? There are CPU, memory, requests and networking properties in the Google Cloud Run pricing table but:
How can I know exactly how much of these resources my application will take?
Could it happen that if the application is publicly available and the requests exceed the free limit quota, I could get an astronomical bill.
Can I set some limits over which my bill cannot exceed?
The billing is quite simple: you pay the CPU time and the memory time that you allocate (and a little bit the number of requests).
The current worst case is: (NbCpu per instance per seconde + Memory per instance per seondes) * 3600 * 24 * 30 * 1000.
3600 is to transform second in hour
24 to transform hour in day
30 to transform day in month
1000 the default max instances parameter
If you want to limit the cost, limit the max instance parameter. But you will also limit the scalability of the application. But that prevent you to have astronomical bill, it's a matter of tradeoffs.
About the billing, you can also set an alert in the budget of your project
Your last question about the quantity of resource used by the application. It's hard to say! However, you have to know your application. The metrics graph can help you to provide some inputs.
However, Cloud Run is able to process up to 80 concurrent requests. Thus your metric when your process only 1 request at a time can change dramatically with 80 request! Especially in memory consumption!
You can also play with this concurrency param to limit the size of one instance. But is you reduce it, don't set the max instance param too low, else some request won't be served.
Matter of tradeoffs
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am looking into purchasing server space with AWS to host what will eventually be over 50 websites. They will have many different ranges of traffic coming in. I would like to know if anyone has a recommendation on what size of server that would be able to handle this many sites.
Also, I was wondering if it's more cost effective/efficient to host an separate EC-2 instance for each site or too purchase a large umbrella server and host all sites on a single instance?
Thanks,
Co-locating services on single/multiple servers is a core architecting decision your firm should make. It will directly impact the performance, security and cost of your systems.
The benefit of having multiple services on the same Amazon EC2 instance is that they can share resources (RAM, CPU) so if one application is busy, it has access to more total resources. This is in contrast to running each one on a separate instance, where there is a smaller, finite quantity of resources. Think of it like car-pooling vs riding motorbikes.
Sharing resources means you can probably lower costs, since you'll need less total capacity.
From a security perspective, running on separate instances is much better because they are isolated from each other. You should also investigate network isolation to prevent potential breaches between instances on the same virtual network.
You should also look at the ability to host all of these services using a multi-tenant system as opposed to 50 completely separate systems. This has further benefits in terms of sharing resources and reducing costs. For example, Salesforce.com doesn't run a separate computer for each customer -- all the customers use the same systems, but security and data is kept separate at the application layer.
Bottom line: There are some major architectural decisions to make if you wish to roll-out secure, performant systems.
The short correct answer:
If those sites are only static(html, css and js). EC2 won't be necessary because you can use S3 and it will be more cheap and you won't have to worry about scaling.
But if those sites have a dynamic part like php, python and similar. Well it is a different story.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have an iOS application, which hits a backend we've set up on AWS. Basically, we have a Staging and a Production environment, with some basic Load Balancing across two AZs (in Production), a small RDS instance, a small Cache instance, some SQS queues processing background tasks, and S3 serving up assets.
The app is in beta, so "Production" has a limited set of users. Right now, it's about 100, but it could be double or so in the coming weeks.
My question is: we had been using t2.micro instances on Staging and for our initial beta users on Production, and they seemed to perform well. As far as I can see, the CPU usage averages less than 10%, and the maximum seems to be about 25 - 30%.
Judging by these metrics, is there any reason not to continue using the t2 instances for the time being and is there anything i'm overlooking as far as how the credit system works, or is it possible that i'm getting "throttled" by the T2s?
For the time being, traffic will be pretty predictable, so there won't be 10K users tomorrow :)
You just need to watch the CPU credits metric on the instances to make sure you dont get throttled. Set up alerts in CloudWatch for this and you should be fine.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm modeling costs for a rest api for an e-commerce application mobile and want to determine the appropriate instance size and numbers.
Our config:
- Apache
- Slim framework PHP
Our Estimation:
- Users/Day: 10000
- Page views / User: 10
- Number total of users: 500 000
- Number total of products: 36 000
That's an extremely difficult question to provide a concrete answer to, primarily because the instance-type most appropriate for you is going to be based on the application requirements. Is the application memory intensive (use the r3 series)? Is it processing intensive (use the c4 series)? If it's a general application that is not particularly memory or processor intensive, you can stick with the M4 series, and if the web application really doesn't do much of anything besides serve up pages, maybe some database access, than you can go with the T2 series.
Some things to keep in mind:
The T2 series instances don't give you 100% of the processor. You are given a % of the processor (base performance) and then credits to use if your application spikes. When you run out of credits, you are dropped down to base performance.
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/t2-instances.html#t2-instances-cpu-credits
t2.nano --> 5%
t2.micro --> 10%
t2.small --> 20%
t2.medium --> 40%
t2.large --> 60%
Each of the instances in each of the EBS-backed series (excluding T2) offer different max throughput to the EBS volume.
https://aws.amazon.com/ec2/instance-types/
If I had to wager a guess, for 100,000 page views per day, assuming the web application does not do very much other than generate the pages, maybe some DB access, I would think a t2.large would suffice with possibility to move up to m4.large as the smallest M4 instance.
But, this all defeats the wonders of AWS. Just spin up an instance and try it for a few days. If you notice it's failing, figure out why (processes taking too long, out of memory errors, etc.), shut down the instance and move up to the next instance.
Also, AWS allows you to easily build fault tolerance into your architecture and to scale-OUT, so if you end up needing 4 processors and 16gb memory (1 x m4.xlarge instance), you may do just as well to have 2 x m4.large instances (2 processors and 8gb memory) behind a load balancer. Now, you have 2 instances with the same specs and roughly the same cost (I think it's marginally cheaper actually).
You can see instance pricing here:
https://aws.amazon.com/ec2/pricing/
You can also put together your (almost) entire AWS architecture costs using this calculator:
http://calculator.s3.amazonaws.com/index.html