Heroku Cloudinary addon vs cloudinary.com.
What's the difference?
https://elements.heroku.com/addons/cloudinary
https://cloudinary.com/pricing
The Heroku plans utilise the classic/legacy Cloudinary plans where the quotas (Transformations, Storage and Bandwidth) are separate.
The new Cloudinary plans are based on credits. This is where any of the 3 quotas, Transformation, Storage and Bandwidth consume a shared pool of Credits. 1 credit equals 1,000 Transformations / 1GB Storage / 1GB Bandwidth.
For example, the Free plan allocates 25 available Credits. It means you can use these 25 credits in any combination between the three quotas as long it totals 25. You can use 5,000 Transformations, 10GB of Storage and 10GB of Bandwidth.
Alternatively, you can use 2,000 Transformations, 20GB of Storage and 3GB of Bandwidth. Or any combination in between the three quotas as long as it adds up to 25 Credits.
Credit based pricing offers more flexibility as they allow you to utilise the entire plan regardless of whether you're using more Transformations/Storage/Bandwidth. On the legacy plans, if you reach the limit of one quota but don't use much of the other two you will still need to upgrade.
Related
Reading the documentation on here I am still not clear of the following points:
Are there any limits on the size of the API request to the Google cloud Storage bucket? (We need to transfer PDFs from a CRM to Google Cloud Storage)
How many files we can send (it mentions a limit of 1000 writes per second) is that the same thing?
Files are the objects you store in Cloud Storage, so the maximum size limit 5 TB should be considered for individual files. There is no limit to write across multiple objects, however buckets support roughly 1000 writes per second and then scale up as needed.
For parallel uploads, please take note that up to 32 objects/files can be composed in a single composition request and a per-project composition rate limit of approximately 1,000 source objects per second.
I also recommend that you take a look at best practices on how to ramp up the request rate
You go with more than 1000 writes per second per bucket - the GCS infrastructure will scale automatically to accommodate it. The only requirement is not to ramp up the load too quickly, namely "double the request rate no faster than every 20 minutes".
https://cloud.google.com/storage/docs/request-rate#ramp-up
I've noticed strange thing happened on my PostgreSQL Amazon RDS Read replica.
We've done "stress-test" of dozens parallel high-load read requests. Performance was really good in the beginning of the test, but then rapidly decreased while PostgresSQL itself kept holding dozens of select queries which were performed fast before it stacked.
I've opened Monitor statistics tab in RDS console and have seen that along with visible performance reducing Read IOPS number also decreased from 3000/sec to 300/sec and didn't go upper then 300/sec iops for long time.
At the same time CPU usage was really low ~3%, there weren't any problems with RAM or storage space.
So my question: are any documented limitations of Read IOPS for read replica? It looks like Amazon RDS automatically reduced high limit of IOPS after really high load (3000/sec).
Read-replica server runs on db.t2.large instance with 100 GB General Purpose (SSD) storage type with disabled fixed IOPS feature.
The behavior you describe is exactly as documented for the underlying storage class GP2.
GP2 is designed to [...] deliver a consistent baseline performance of 3 IOPS/GB
GP2 volumes smaller than 1 TB can also burst up to 3,000 IOPS.
https://aws.amazon.com/ebs/details/
3 IOPS/GB on a 100GB volume is 300 IOPS.
See also http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/EBSVolumeTypes.html for a description of how IOPS credits work. While your system isn't busy, it will build up credits that can be used for the next burst.
As I understand it, RDS Provisioned IOPS is quite expensive compared to standard I/O rate.
In Tokyo region, P-IOPS rate is 0.15$/GB, 0.12$/IOP for standard deployment. (Double the price for Multi-AZ deployment...)
For P-IOPS, the minimum required storage is 100GB, IOP is 1000.
Therefore, starting cost for P-IOPS is 135$ excluding instance pricing.
For my case, using P-IOPS costs about 100X more than using standard I/O rate.
This may be a very subjective question, but please give some opinion.
In the most optimized database for RDS P-IOPS, would the performance be worth the price?
or
The AWS site gives some insights on how P-IOPS can benefit the performance. Is there any actual benchmark?
SELF ANSWER
In addition to the answer that zeroSkillz wrote, I did some more research. However, please note that I am not an expert on reading database benchmarks. Also, the benchmark and the answer was based on EBS.
According to an article written by "Rodrigo Campos", the performance does actually improve significantly.
From 1000 IOPS to 2000 IOPS, the read/write(including random read/write) performance doubles. From what zeroSkillz said, the standard EBS block provices about 100 IOPS. Imagine the improvement on performance when 100 IOPS goes up to 1000 IOPS(which is the minimum IOPS for P-IOPS deployment).
Conclusion
According to the benchmark, the performance/price seems reasonable. For performance critical situations, I guess some people or companies should choose P-IOPS even when they are charged 100X more.
However, if I were a financial consultant in a small or medium business, I would just scale-up(as in CPU, memory) on my RDS instances gradually until the performance/price matches P-IOPS.
Ok. This is a bad question because it doesn't mention the size of the allocated storage or any other details of the setup. We use RDS and it has its pluses and minuses. First- you can't use an ephemeral storage device with RDS. You cant even access the storage device directly when using the RDS service.
That being said - the storage medium for RDS is presumed to be based on a variant of EBS from amazon. Performance for standard IOPS depends on the size of the volume and there are many sources stating that above 100GB storage they start to "stripe" EBS volumes. This provides better average case data access both on read and write.
We run currently about 300GB of storage allocation and can get 2k write IOP and 1k IOP about 85% of the time over a several hour time period. We use datadog to log this so we can actually see. We've seen bursts of up to 4k write IOPs, but nothing sustained like that.
The main symptom we see from an application side is lock contention if the IOPS for writing is not enough. The number and frequency you get of these in your application logs will give you symptoms for exhausting the IOPS of standard RDS. You can also use a service like datadog to monitor the IOPS.
The problem with provisioned IOPS is they assume steady state volumes of writes / reads in order to be cost effective. This is almost never a realistic use case and is the reason Amazon started cloud services to fix. The only assurance you get with P-IOPS is that you'll get a max throughput capability reserved. If don't use it, you pay for it still.
If you're ok with running replicas, we recommend running a read-only replica as a NON-RDS instance, and putting it on a regular EC2 instance. You can get better read-IOPS at a much cheaper price by managing the replica yourself. We even setup replicas outside AWS using stunnel and put SSD drives as the primary block device and we get ridiculous read speeds for our reporting systems - literally 100 times faster than we get from RDS.
I hope this helps give some real world details. In short, in my opinion - unless you must ensure a certain level of throughput capability (or your application will fail) on a constant basis (or at any given point) there are better alternatives to provisioned-IOPS including read-write splitting with read-replicas memcache etc.
So, I just got off of a call with an Amazon System Engineer, and he had some interesting insights related to this question. (ie. this is 2nd hand knowledge.)
standard EBS blocks can handle bursty traffic well, but eventually it will taper off to about 100 iops. There were several alternatives that this engineer suggested.
some customers use multiple small EBS blocks and stripe them. This will improve IOPS, and be the most cost effective. You don't need to worry about mirroring because EBS is mirrored behind the scenes.
some customers use the ephemeral storage on the EC2 instance. (or RDS instance) and have multiple slaves to "ensure" durabilty. The ephemeral storage is local storage and much faster than EBS. You can even use SSD provisioned EC2 instances.
some customers will configure the master to use provisioned IOPS, or SSD ephemeral storage, then use standard EBS storage for the slave(s). Expected performance is good, but failover performance is degraded (but still available)
anyway, If you decide to use any of these strategies, I would recheck with amazon to make sure I haven't forgotten any important steps. As I said before, this is 2nd hand knowledge.
From the Amazon RDS FAQ Page
http://aws.amazon.com/rds/faqs/
"Depending on the size of storage requested, Amazon RDS automatically stripes across multiple EBS volumes to enhance IOPS performance"
What disk size do I need to request to trigger disk striping? I've only heard rumors of 300GB.
I had a conversation with upper management at AWS regarding this. Here is the direct answer provided by them.
You will realize improvements with RDS throughput by scaling storage as high as 500GB, and this effect starts at a level well under 100GB (ie: striping occurs at a far lower level than 300GB).
The most important factor in realizing this throughput potential is the instance class. Specifically, the following instance classes are considered High I/O instances:
m1.xlarge
m2.2xlarge
m2.4xlarge
These instances have large network bandwidth available to them, so the upgrade that you mentioned on stackoverflow (to the m2.2xlarge instance) was likely the main reason you saw a leap in throughput. If you stripe your current storage as high as 500GB, this will continue to increase. With provisioned IOPS support for RDS (PIOPS-announced last night), throughput will now scale linearly all the way to 1TB.
With PIOPS, the throughput rate you can expect is currently associated with the amount of allocated storage. For Oracle and MySQL databases, you will realize a very consistent 1,000 IOPS for each 100GB you allocate – resulting in a potential throughput max of 10K IOPS. The (current, temporary) downside is that you will need to unload/load data to migrate an existing app to the PIOPS RDS.
Last I checked 300gb triggers back-end striping
I was told recently by an AWS engineer on an architecture review that 100GB will trigger EBS striping
I have an ASP.net web application deployed on the small AWS instance (Dual Core AMD, 2.60 GHz, 1.7 GB RAM). I would like to perform load testing on this server for 300 concurrent users and for future, I want to design the tentative capacity planning and deployment architecture for 250,000 registered users for my application.
I am very new person in this area and have not done any kind of load testing before.
The Use-case and scenario of my
application will be as below:
Scenario - 250, 000 registered users in database
Concurrency – 5% - 7% - approximately 17,500
Each user has a book shelf and
assuming each user is subscribed for
10 books. Each book is of around 25 MB
in size with 400 pages
Use cases
User Login
Database authentication & authorization
View Book Shelf with book images
Book Shelf (.swf) - 400 KB (gets loaded for each user)
10 book images will be loaded (20KB per image)(approximately)
catalog.xml - 30 KB / user for allocated for the user
Note: Approximately 650KB of data is gets downloaded on to client
machine
Browse book : On clicking a book image following files & its sizes will
be downloaded to clients machine
One time
Reader.swf - 950 KB (first download)
XML data’s of approximately 100 KB / per book (on click)
Book.xml
Annotation.xml
Catalog.xml
Usersettings.xml 40KB*4 = 160 KB per user (.swf)
Note: Approximately 1200KB of data is gets downloaded on to client
machine
Could someone please suggest how can I proceed with this?
Very much thanks in advance,
Amar
Completing the first goal (test 300 users) is pretty straightforward - choose a load testing tool, build the scenarios and test. Then tune/optimize and repeat.
But I think your bigger question is how to approach testing and planning for your full capacity - which you say is ~18k concurrent users. First, make sure that number (7% of user base) is the peak concurrency, not average. You need to test the peak.
So assuming that you are planning a load-balanced multiple-server cluster to handle that load, the next step is to determine the maximum capacity of a single web/app server, without the load-balancer in place. This gives you a baseline that you can use to judge the performance of the cluster. This is a really important step and many of our clients skip this step, to their own detriment. It is important because there are many conditions under which a load-balanced system does not scale linearly with the number of servers in the cluster. Ideally it should and good systems get pretty close. You'd be surprised how frequently we see systems that don't scale well at all. We've even seen a few systems that actually have lower capacity as a cluster than a single server could handle on its own.
Once you have that baseline established, you can make a preliminary estimate about the total number of servers you'll need and you can build your cluster. I recommend next testing with 2 web/app servers. This should nearly double your capacity. If it doesn't then you need to determine why before moving on to larger tests. Likely candidates are the load balancer setup or the database (if a single database server is servicing all the web/app servers). Occasionally something more fundamental to the application architecture is at play.
When you are satisfied that scaling from 1 to 2 servers is performing optimally, then you can proceed to scale up to your full cluster and test maximum capacity. Be prepared to back-track if you don't see the scalability you expected - test with 3, 4, 5 servers, etc.
I hope that helps! Good luck :>
This link: http://support.microsoft.com/kb/231282, has links to some tools to stress test your website.
This is obviously a complicated area, so you may have 2.5 million registered users (really that many?), but how many are concurrent, and what areas of the website will they be using.
All of these things (and many more), will impact the capacity planning for your system.