Storage/Traffic usage for different features (chat,content...) - quickblox

since Quickblox plans have a storage/Traffic limitation lets say 50Gb. I am trying to figure out the Storage/Traffic usage of the features, chat, user, custom objects, content and video in terms of the limitation (I am calling it usage charge)
1) Chat - Is there a traffic usage charge for every chat message sent/received?
2) Custom Object - I assume to store objects there is a storage usage charge but is there a traffic usage charge each time I access the objects (API calls should be free)?
3) Content - I assume to store content there is a storage usage charge but is there a traffic usage charge each time I access the content (API calls should be free)?
4) Video - supposed to be free?
Thanks.

API calls are free, you're right
10 GB storage: it's only about Content files (not Custom Objects records/Chat messages/Users etc.)
10 GB traffic: actually download/upload files from/to Content module produces the main traffic. API calls - it's really small amount of traffic, don't worry about it.

Related

ActiveCollab API - requesting Daily Capacity

ActiveCollab has some very strong features in the UI related to resource management - capacity, scheduling, workload, calendars etc.
I would like to access these data set via the API, but nothing seems to be available per the documentation here: https://developers.activecollab.com/api-documentation/index.html (except Days-off)
Specifically, I'm looking to request daily capacity for all users.
No googling or dialogue with their support have been able to point me to an answer.

Youtube API's maximum number of video uploads per day

We are building an app with a video upload functionality. We were wondering if we could use a Youtube account to upload all of our user videos. They should only be accessible via our app... we don't mind if ads show up while viewing them.
If the app grows, we're looking at potential thousands of uploads per day.
Does Youtube support this? If a few videos get flagged, will the "master" account be shut down?
Finally, if Youtube is the not right choice, do you have any recommendation? We would like to avoid hosting them as much as possible... Since streaming large amounts of videos is an enormous challenge for a start up.
Thank you!
Some information on the video uploads:
https://developers.google.com/youtube/v3/docs/videos/insert
This method supports media upload. Uploaded files must conform to
these constraints: Maximum file size: 128GB Accepted Media MIME types:
video/*, application/octet-stream
You can get the qouta information here: https://developers.google.com/youtube/v3/getting-started#quota
Projects that enable the YouTube Data API have a default quota
allocation of 1 million units per day, an amount sufficient for the
overwhelming majority of our API users.
...
Different types of operations have different quota costs.
A simple read operation that only retrieves the ID of each returned
resource has a cost of approximately 1 unit. A write operation has a
cost of approximately 50 units. A video upload has a cost of
approximately 1600 units.
Yes, youtube can block API access, not only on flagged videos, but at any time as described here: https://developers.google.com/youtube/terms/api-services-terms-of-service#termination
24.2 Termination by YouTube. Notwithstanding anything to the contrary, YouTube reserves the right to (i) suspend or terminate access to, or
use of, any aspects of the YouTube API Services by you, your API
Client(s) and those acting on your behalf), and (ii) terminate the
Agreement (or any portion thereof), as applied to any specific user or
API Client, category of users or API Clients, or all users or API
Clients at any time. For example, we may need to exercise such rights
in instances of your breach of this Agreement, court order, when we
believe there to have been misconduct or conduct which may create
potential liability for YouTube or its Affiliates. Although we will
try to give you reasonable notice, we have no obligation to do so.

Graph API /threads messages usage limitations

With regards of using the /threads object from Graph API I want to know if a public figure account has some limitation regarding the amount of received messages / day and to know if a Facebook application that reads them using /threads has limitation to access the entire list.
Suppose I develop an app used by a public figure that would receive 500k(or above) messages a day. Can I access all the messages (using a paging technique, of course)? Is there any chance to have the account removed or app disabled because of extensive usage of messages? If there is a need to pay for an account (and-or application) with such a usage, where do I find the pricing list?
Thank you.

Azure number of instance and bandwidth usage

I would like to know how to find badwith usage and number of instance for azure. Is these features available in azure api ?
Bandwidth usage no. It is only tracked in billing and that currently has no open API. You can track bandwidth usage yourself if you funnel every request thru programmable API that can capture the size of data they're pushing out. (Incoming data is now free).
Number of instances, yes. Two ways to do this:
1) If done from "outside" of your deployment, you can use Service Management API to navigate to a specific Deployment and call this method: http://msdn.microsoft.com/en-us/library/ee460804.aspx
2) If done inside a role, you can use RoleEnvironment.Roles["role-name"].Instances.Count

API, building an API but giving priority access for certain requests

Not sure how others have addressed this, but generally speaking what is the best practice for giving your own apps priority treatment when it comes to using one of your own public APIs?
Use Cache Priority
Caching responses or interim calculations in RAM is typically the first optimization point because caching is easier than micro optimizing all your code. Controlling what goes into the cache and how long it stays presents a top level place to apply "priority treatment".
I like the cache management approach better than thread priority because if you are under load delaying the execution of a request often creates complex thread pool problems and decreases overall server throughput.
Caching Based on Load (rather than on app ownership) will Expand the Resource Pie
We take the ram cache priority approach with MapLarge Tile Server and Geocoding API. However, we don't actually give our own apps priority, instead we base priority on request frequency and time required to render a response. Unless you have large numbers of low value api users, I would recommend doing something similar because this approach should reduce overall load and enables the server to handle more api requests.
I recently wrote a white paper that highlights the different load profiles of cached and non cached responses in a multi tenant api environment. You can see it here:
http://maplarge.com/Tile-Server-Performance
API Policies can drive revenue
If you have free or low paying users who are generating massive load you might want to review your business plan and consider instituting account based rate limits that match user revenue to server costs in a scalable way. If you do limit API users I would recommend having explicit and predictable policies so they can project usage and know when to purchase an API account upgrade.