I have a deployed model on sagemaker with two production variants. I was wondering if you get charged for both variants even if I set all the traffic to just go through one of them.
The docs on pricing are found below but I couldn't seem to find the answer to this.
https://aws.amazon.com/sagemaker/pricing/
You will be charged as long as the model is running on an instance regardless of whether the traffic is going through it or not as still the model is running on an instance.
Related
I aim to create an application that will be deployed thanks to Google App Engine.
Before that I would like to calculate the cost of Google App Engine.
For this I have to provide the Number of instances, per hour. How can caluculate this number of Instances ?
To reformulate, imagine I have 1 thousand users connected, how many users can 1 instance afford ?
Thank you for your answer and help
Regards
Benoit
It's really hard to answer without more info. App engine consumption will depend on the nature of your app, the average session span and usage hours, how well you optimize your implementation and so much more variables...
Don't think about how many instances, think about how many instance hours you'll need to serve your users if you can figure how much you'll be consuming you could get an estimate using the App engine pricing calculator .
Completely depends on the code that runs on each request. You need to make it more specific to get a better answer. Ive had carefully implemented apps that receives thousands of requests per minute with a single instance. How long each request takes and the memory it consumes is key as well as the frontend instance type you select to use.
Appengine also lets you calibrate some parameters like min/max latency to control when more instances are launched.
I'm very new to using Google cloud services. As I can see Google App Engine has two way of deployment. The first one is using App Engine sandbox and the second is managed VM.
So I'm interested in pricing. Is there any difference in price? For example if I choose managed VM instead sandbox.
Pricing for the Sandbox can be found on the App Engine Pricing page.
Pricing for the Managed VM's can be found on the Compute Engine Pricing page:
While in beta, pricing is based on Compute Engine Pricing for each VM. Pricing will change in the future.
Based on the linked Price pages:
The Minimum cost for a Sandboxed instance: $0.05 / hour (F1 class, 128MB RAM, 600MHz CPU)
The Minimum cost for a Managed VM: $0.063 (n1-standard-1, 3.75GB RAM, 2.75GCEU CPU)
For other classes of sandbox instances see this page: Adjusting Application Performance
Before jumping to the conclusion that Managed VMs are cheaper: each app gets 28 free instance-hours per day for Sandbox, so chances are good you won't even have to pay for any. Also with further configuration you can achieve to only pay for further "used" instance hours (e.g. you can play with min_idle_instances and max_idle_instances in your module config so additional instances only count toward instance hour billing when they are active (serving requests)).
Notes:
Price shouldn't be the only (or most important) reason to chose one over the other. They are for different things with quite different characteristics.
Sandbox instances are primarily for your application front-end: they can automatically scale as your traffic changes/grows. Many restrictions are enforced.
Managed VMs are good for background operations which can be long or CPU consuming, most of the restrictions are not applied.
In a nutshell: MVMs are for the same price about 10x more powerful.
Default GAE instances are F1: 600Mhz, 128MB, $0.05/h
Comparable MVM: 2500Mhz, 3.75GB, $0.05/h (typical use)
It's not about price, it's about environment. You would not have SQL or root FS on GAE, you can't open ports. Your code base would be hard to migrate to another VPS. As a trade-off you get zero cost maintenance and effortless instant scaling.
I have a background in web programming where both the data and the code live on the server. Web hosts with mysql or the like are plentiful and cheap so using the application from multiple pcs was never a problem.
However I'm considering switching to building desktop applications but the only factor that annoys me is the syncing of data across the many pcs I use. I was thinking of perhaps setting up a light amazon ec2 instance with a postgresql on it and having my desktop applications use that.
I have a few questions:
I'm curious as to what latency I might expect by running the database on ec2 instead of the local network, any experience or insight is appreciated.
Are there better/more obvious/cheaper solutions?
I've looked at the pricing and it seems to come down to 24.48$ per month for a yearly contract. Whilst not really expensive, it is not exactly cheap either. At what point does it become more interesting to run a local server?
I'm obviously not using my applications for large parts of the day (sleep, work,...). I was wondering if I can have the amazon server go into a sort of "sleep" mode and wake up when poked. An initial delay for the first desktop application is acceptable. The reason behind this behavior would be to save money on the instance if it is only actually needed for 10% of the day.
I welcome any feedback at all on how this problem is best tackled.
This could get ugly. Every single query you do will have latency associated with it. If you have a lot of queries, this can add up very fast. So keep your query count low, and try to pre-fetch and cache data when possible.
Not enough information to answer that question.
Depends on the cost of your local server. Keep in mind that you will need to pay for electricity to keep it on.
You can stop your instance when you are not needing it, with the exception of high utilization reservations, you wont get billed when its in stopped state. With high utilization reservations you will still pay the full cost.
I developed an application for client that uses Play framework 1.x and runs on GAE. The app works great, but sometimes is crazy slow. It takes around 30 seconds to load simple page but sometimes it runs faster - no code change whatsoever.
Are there any way to identify why it's running slow? I tried to contact support but I couldnt find any telephone number or email. Also there is no response on official google group.
How would you approach this problem? Currently my customer is very angry because of slow loading time, but switching to other provider is last option at the moment.
Use GAE Appstats to profile your remote procedure calls. All of the RPCs are slow (Google Cloud Storage, Google Cloud SQL, ...), so if you can reduce the amount of RPCs or can use some caching datastructures, use them -> your application will be much faster. But you can see with appstats which parts are slow and if they need attention :) .
For example, I've created a Google Cloud Storage cache for my application and decreased execution time from 2 minutes to under 30 seconds. The RPCs are a bottleneck in the GAE.
Google does not usually provide a contact support for a lot of services. The issue described about google app engine slowness is probably caused by a cold start. Google app engine front-end instances sleep after about 15 minutes. You could write a cron job to ping instances every 14 minutes to keep the nodes up.
Combining some answers and adding a few things to check:
Debug using app stats. Look for "staircase" situations and RPC calls. Maybe something in your app is triggering RPC calls at certain points that don't happen in your logic all the time.
Tweak your instance settings. Add some permanent/resident instances and see if that makes a difference. If you are spinning up new instances, things will be slow, for probably around the time frame (30 seconds or more) you describe. It will seem random. It's not just how many instances, but what combinations of the sliders you are using (you can actually hurt yourself with too little/many).
Look at your app itself. Are you doing lots of memory allocations in the JVM? Allocating/freeing memory is inherently a slow operation and can cause freezes. Are you sure your freezing is not a JVM issue? Try replicating the problem locally and tweak the JVM xmx and xms settings and see if you find similar behavior. Also profile your application locally for memory/performance issues. You can cut down on allocations using pooling, DI containers, etc.
Are you running any sort of cron jobs/processing on your front-end servers? Try to move as much as you can to background tasks such as sending emails. The intervals may seem random, but it can be a result of things happening depending on your job settings. 9 am every day may not mean what you think depending on the cron/task options. A corollary - move things to back-end servers and pull queues.
It's tough to give you a good answer without more information. The best someone here can do is give you a starting point, which pretty much every answer here already has.
By making at least one instance permanent, you get a great improvement in the first use. It takes about 15 sec. to load the application in the instance, which is why you experience long request times, when nobody has been using the application for a while
I never used Amazon EC2 or RDS Service. I am trying to calculate my cost using http://calculator.s3.amazonaws.com/calc5.html
I searched a little but could locate answers to some basic things. Can you help me out with this:
What does DB Instance means? 1 Database = 1 Instance or 1 Connection = 1 Instance
How to calculate hours/month usage? It should depend on the transfer rates or processing time. Is there a way I can get rough Idea about it?
What if I already have my DB Ready and want to upload it directly (it would be few GBs) then how will it be calculated.
I am new to amazon EC2 and searched stackoverflow and serverfault before posting this question. Got some idea but not specific what I am looking for. Can someone help me out here?
In general, one database = one instance. You spin up instances, and do what you like with them. Definitely possible to have more connections to it.
Hours per month is just that. How many hours per month you have the instance active. If you plan to have the instance active 24/7, you may find more cost effective alternatives with other cloud providers. If you run it less often than that, you save money when it's not active. It's billed hourly to your account at the rate specified.
Upload data is counted at the standard transfer rates. A few GBs doesn't cost much, but you will be paying for the service starting the moment you spin up the instance.