Coundant standatd plan is written as "100 reads / sec, 50 writes / sec, 5 global queries / sec".
Is this IO/s calculate end-to-end request? Or is it based on the query execution plan?
Let's give some examples
Q1.Let's say I use a Bulk operation to create 3 new documents in Cloudant (Bluemix Standard plan).
1 write operation? 3 write operation?
Q2. Query by aggregation(join)-1000 indexed docs with "name, age range, join time" and get as one docs.
1 read? 1000 + 1 read?
Q3. When I am using the standard plan (limit 100 reads / sec), it is assumed that 100 users executed the query in (Q2) at the same time.
How is IO calculated? 1 * 100 reads? (1000 + 1) * reads?
Do some users fail to execute queries because of limitation IO?
There is no data listed properly about Cloudant Price Method.
Can anyone please point me out correctly?
I want to know exactly how the standard plan calculation is measured.
It would be better if you could add a calculation example and answer!
Also answered here, https://developer.ibm.com/answers/questions/525190/how-do-calculate-io-operations-in-cloudant-account/
Bulk operations currently count as 1 W, regardless of the number of docs it contains.
A query is a request to a URL that has one of _design, _find or _search, again unreated to the number of documents actually involved. Note that some of these API endpoins (search) are paged, so it would be 1 Query per requested page of results.
I assume that by "100 users" you mean 100 concurrent connections using the same credentials, as Cloudant's rate limiting is applied per account. If so, the sum total of requests are counted towards the limit. When that bucket is full, any further requests will be cut off, and failed with a 429: Too Many Requests HTTP status code.
As an example, let's say you have a Standard account where you've set the rate limit to allow 100 queries per second. You have 100 concurrent connections hitting _find repeatedly, each query returning 1000 documents. Cloudant will allow 100 queries per second, so on average each of your connections will get 1 query per second fulfilled, and any attempts to push harder than that will results in 429 http errors. With 10 concurrent connections, on average each will get 10 qps etc.
Cloudant rate limits at the http level. No splitting of bulk ops into the constituent parts take place, at least not yet.
Documentation for how this all hangs together can be found here: https://cloud.ibm.com/docs/services/Cloudant?topic=cloudant-pricing#pricing"
The Cloudant offering in the IBM Cloud Catalog has a link to the documentation. In the docs is a description of the plans with additional examples. The docs also have sections that explain how read and write operations are calculated.
The http code 429 is returned by Cloudant to indicate too many requests. The documentation discusses this fact and there are code samples on how to handle it.
Related
Consider a brokerage platform where customers can see all the securities they hold. There is an API which supports the brokerage frontend by providing all the securities data corresponding to a customer Id.
Now this api has a tps of 6000, that is what it is certified for.
And the SLA for this api is 500ms, and 99th percentile response time is 200ms.
The API is hosted on aws, where the servers are autoscaled.
I have few questions:
At peak traffic, the num of users on frontend is in hundreds of thousands if not million. How does the tps relate with the number of users ?
My understanding is that tps is the number of transactions which the api can process in a second. So, the number 6000 for the api, is it for one server or for one thread in a server? And let's say if we add 5 servers, then the cumulative tps would become 30,000 ?
How do we decide the configuration (core, ram) of each server if we know the tps ?
And finally, is the number of servers basically [total num of users / tps] ?
I tried reading about it in couple of books and few blogs, but I wasn't able to clear my confusion entirely.
Kindly correct me if I am asking the wrong questions or if the questions doesn't make sense.
As per the Google Firebase documentation, Firestore will support upto 1,000,000 simultaneous connections and 10,000 writes per second per database. We have ran a scalalbility test to check the Firestore is viable for our solution and encountering the errors like "Connect to firebase.googleapis.com:443:Connection timed out" during write operations for 40K samples, "firestore.googleapis.com:443:failed to respond" during GET operations while the 40K samples writing. Would like to understand the Firestore limits and its scalalbility
Running JMeter script to write data to Firebase (Firestore Blaze Plan purchased for testing) on multiple VMs and PCs which are connected to wired network to check the scalalbility. The JMeter script write data to Firebase using REST API PATCH and each script on PC/VM writes 5K data in a period 5 minutes. There are total of 8 PC/VM which writes 40K data to Firebase. During this we also GET 500 records in 5 minutes 2 times a day. During this test we are htting the Firebase failures
The errors are "Connect to firebase.googleapis.com:443:Connection timed out" during write operations for 40K samples, "firestore.googleapis.com:443:failed to respond" and Connection reset.
Are you considering the other limits for your specific operations?
According to https://firebase.google.com/docs/firestore/quotas
For example, for the write operation:
Maximum writes per second per database = 10,000 (up to 10 MiB per second)
Maximum write rate to a document= 1 per second
Maximum write rate to a collection in which documents contain sequential values in an indexed field = 500 per second
Maximum number of writes that can be passed to a Commit operation or performed in a transaction = 500
During GET operations you have the limits: Maximum number of exists(), get(), and getAfter() calls per request:
10 for single-document requests and query requests.
20 for multi-document reads, transactions, and batched writes. The previous limit of 10 also applies to each operation.
For example, imagine you create a batched write request with 3 write operations and that your security rules use 2 document access calls to validate each write. In this case, each write uses 2 of its 10 access calls and the batched write request uses 6 of its 20 access calls.
Exceeding either limit results in a permission denied error.
Some document access calls may be cached, and cached calls do not count towards the limits.
I think that some parameter could be causing the abortion of these connections.
We are switching to the new Discovery service from the Retrieve and Rank service on Bluemix. This requires quite a bit of code rewrite and I'm getting a strange error message while transferring our answer units to Discovery:
Error: The service is busy processing 20 of your documents. Please wait for some of the documents to complete, then try again.
Is there some kind of rate limit on inserting documents into Discovery? If so, how do we increase or better, eliminate it?
Yes, there is a rate limit for inserting documents into Watson Discovery. Larger environment sizes have higher rate limits, but every size does have a limit.
Background
The big difference between sending a document into Retrieve and Rank compared to Discovery is that sending a document into Retrieve and Rank is synchronous but sending a document into Discovery is asynchronous.
Retrieve and Rank will not respond to an API call to index a document until the processing is complete. Discovery responds as soon as the document has been accepted into the pipeline for processing and processing is likely to take several seconds to complete.
Discovery limits the number of documents in the processing pipeline per service instance and returns a 429 status when the limit is exceeded.
Retrieve and Rank has what amounts to the same kind of restriction: limiting the number of concurrent requests for a single service instance.
Is there any limit of concurrent queries that mongodb can run in a second?
I am trying to implement an API that runs 300 queries in each request in mongodb.
So if there are 100 client requests in a second so the number of queries becomes 100 x 300 which is resulting in high latency.
Any clue?
The only limit is the number of conections mongo can have in parallel. Check out net.maxIncomingConnections
The maximum number of simultaneous connections that mongos or mongod will accept. This setting has no effect if it is higher than
your operating system’s configured maximum connection tracking
threshold.
But still you'll need to monitor your system to figure out what's actually happening.
And yes, 300 queries per API request is a bit too much even from networking perspective/requests parsing overhead.
I am trying to understand whether read latency stats obtained through
nodetool cfstats
nodetool cfhistograms
, will count each read within secondary index queries separately.
I guess the answer might depend on whether secondary index queries are handled by thrift clients or internally by Cassandra. I don't know that either.
[1] Cassandra - cfstats and meaning of read/write latency
Cassandra read latency is calculated with calculating average time taken by each read query.
In that a single get query or multiget query is considered as a single read and average is calculated.[ StorageProxy.read() is the function where Cassandra is collecting time taken for each query ]