Hi Mark,
Your argument for supporting peak level pricing makes me feel that my app is alone on your infrastructure. Platform providers are sharing resources across applications. A single app cannot take the risk of unpredictable peak levels. This unpredictability is even very high for apps with a low number of users. I would expect that the platform provider is taking the risk of peak levels. Because he can average over a large number of apps, the predictability of API access is much higher.
Another part of your argument is the 24h number. Why 24 hours? If you would go for 12 hours, would this imply half of the costs for apps?
Regards,
1 Like
We study how apps run all the time. The analysis is based on the review of thousands of apps. The 24 period is the most reasonable cycle that yields the best performance for the applications.
Regards,
Mark
Right but your flat rate plan in the past was meant to support a Tier 7 user based on the API call limits that Cloud9 was priced around. So in my mind, and I think from reading this thread many of us, that a user that is around that 224 calls per minute should be considered a âlight userâ where a user that spikes up to 900 api calls(4Xâs the cloud9)or more for a minute would be more in line to what was the cloud 99 plan.
@mark-piller Iâve emailed you twice on our specific concerns about the cycle our apps go through and what that means to us in the new pricing model without a response, in addition to the concerns laid out in that email(heavy initial app use that gradually lowers over a few months to what would be considered normal)weâve been watching very closely the app that we have been using in our development and its sitting at $110 right now and will likely spike tomorrow due to what we have been working on over the last couple of days. The new model will drastically reduce our ability to continually develop new and exciting features in our apps, we donât charge more because of a new feature we provide to our customers but our costs will go up as those new features are added and utilized.
If the tiers can get us back to something resembling the pricing that made Backendless a very attractive solution to build our business model on(we are a young startup still)then Iâm sure we can continue this relationship in a way that benefits everyone involvedâŚbut right now as things stand I have been forced to start looking at alternatives that will allow me to keep our service costs stable rather than what right now is looking to be a wildly fluctuating cost structure.
1 Like
This is what seems to be âbrokenâ in the new pricing model. The single minute 10 or 11 api call app for 1X in a day utilized exactly that 10 or 11 api calls. Where the 10-11 api call for every minute of the day made between 14440 and 15840 api calls that day. Each of the above apps where charged .99 or 1.75 for the day.
So in our specific example we made 8,178 calls over May 19th and May 20th, our peak per minute rate on those days was 741 and 548 which put us into the tier 9 or $25/day rate. Our average callâs per minute over that 48 hour period was 2.84. I wouldnât think this classifies as heavy use?
What was conveyed to me in the webinar was these changes are needed to ensure that the heavy users that warranted the hardware resources are being billed accordingly, what is in fact happening is everyone is being billed as though they are heavy usersâŚjust in case that one day they might end up being a heavy user.
How about billing us based on actual API calls? Give us a rate scale based on volumes and by all means bill me actual usage and not anticipated usage because I had a one minute spike on a particular day or days.
Donât get me wrong, Iâm not saying that our rate for the usage I outlined above should be at the .50 per day rate, but I do not think it should escalate us into the 25.00 per day range either.
3 Likes
I agree that a total API usage rate would be a lot fairer and easier to predict for developers. A lot of apps including Matts example and my own app will have spikes at certain times of day which then die down to a much lower baseline value.
Any comments on the suggested tool? As it stands itâs still not clear to me which API calls count towards billing. It appears that come cloud code operations are being counted on the performance graph, is that correct?
Can we please have a definitive list of API calls that are counted? Can we please have a tool to understand exactly what API calls are being made? As it stands, operations that occur in my cloud close are appearing under âall clientsâ on the API calls page - is this correct?
Mitch
1 Like
The rule is simple, any time you make a request into Backendless, it is an API call. The request can come from a mobile app, web app, third-party app (callbacks), or calls made from Cloud Code. All of these are API calls and they are accounted for.
Heavy use or a light one, it is strictly subjective. When you make more calls, it will cost more. The cost is defined by the tier that day lands itself in.
@Matt_Olson, I will respond to your email today. I didnât ignore it, it is on my to-do list.
Than you for clarifying @mark-piller, can you please clarify if number of push messages sent via API in a minute counts? (the number of clients receiving a message I mean, not the call to initiate the messages)
We still do not have a tool to see exactly which API calls are asking for more resources on back endless. Sure we can see number of API calls on the API calls tab, but it cannot be broken down into per minute, so we cannot correlate⌠i.e. which cloud code timer did the API call come from? What was the call? What was the line number? Which event handler was triggered? etc etc
We do not capture information you described. The simplest way to find that correlation is:
If the app doesnât have live/production traffic: make you are the only user (ask other devs in the team to pause their activities). Run a timer (Backendless console lets you do that on demand). Once the timer finishes, navigate to Manage > Analytics > API calls. Select âTodayâ. See what API calls are shown. That will tell you both timing as well as the actual calls. The same process works for event handlers, services as well as the client (UI) app.
If the app has production traffic, you would need to isolate it so you can study where the calls are made from. The simplest way to do it is by cloning your app and perform the process described above with the cloned app.
Hope this helps.
Regards,
Mark
Thanks @mark-piller - does the number of push notifications sent via API count towards calls per minute? For example if I do a single call to a push single cast containing 200 device IDs, does this count as 200 API calls or 1 API call?
Hi @mark-piller so the issue for me is multiple timers. As part of my cloud code business logic, I have three timers that each run every minute. Each timer on its own uses between 10-50 API calls, however if more than one timer triggers at the same time, or within one minute of the previous timer, the aggregated API calls for that minute are cumulative between each timer. This results in occasional spikes throughout the day of up to 200-250 API calls per minute.
Do you have any advice on how multiple timers can be run but ensuring no overlap of execution? If they are all started exactly 1 minute after each other, will that spacing be maintained on an ongoing basis? I need to split into 3 timers as a single timer may go over the maximum 20 second allowable run time. Timing is not critical, for example if each timer ran within a distinct minute window one after the other and it took 3 minutes to come around to the first timer again, that is not critical.
Any advice how to work around this?
Hi @mark-piller.
Consider the following example:
DataQueryBuilder queryBuilder = DataQueryBuilder.create();
queryBuilder.setPageSize(100).setOffset(0);
String whereClause = "criteria = 'dailyChangeMorning'";
queryBuilder.setWhereClause(whereClause);
List<DailyAlert> dailyAlertsList = Backendless.Data.of(DailyAlert.class).find(queryBuilder);
This API call returns an array of 100 objects from a table in backendless. In the scale plan, should this count as 1 API call (i.e. the single query to the server) or 100 API calls (i.e. the number of rows returned from the table)?
Thanks
Thanks for that. Can you please let me know the different between a ârequestâ and a âconcurrent requestâ on the API performance page of the console?
Can you let me know if push notifications make any different to either of these metrics?
For example, a single API call could send a push notification to single device, this would clearly count as 1 API call. If the same single API call was given an array of 100 device IDs and send a push notification to all 100 devices, would that count as 100 API calls or 1 API call?
Thanks
Mitch
Hi @mitchell ,
Concurrent requests are requests whose execution overlaps on the timeline. These typically are long-running requests and primarily are requests for custom API services.
When you send push notifications, you will send 1 API request to send X push notifications. The X metric will count towards the push notification limit (see âPush Notificationsâ line on the pricing page):
Regards,
Mark
I donât believe my app has any published containers, but it does have a landing page. Iâm assuming thatâs what is causing my âFile Downloadâ api count, which is about 10x larger than my next closest call type.
Can someone point me to a resource on how to remove / disable / unpublish landing pages and / or frontend app components?
Hi Charles,
Any published UI containers would be in the hierarchy of the /web directory which is accessible through the Files section in Backendless console. Deleting files from there would remove access to the landing pages.
Regards,
Mark
1 Like
I think I see the issue now. I let users upload photos (profile pic, photo albums, etc.) on my app When I send one get collection API, that can pull in multiple pictures. Because those images are stored in the file folder, is that causing the File Download api to trigger?
So essentially I send 1 get collection API that has 10 pictures, Iâm being charged for 11 API calls - 1 for the get collection, 10 for the file download api to reference the pictures in the file folder.
Is there a better way that I should have built this?
hello @Charles_Fields
to decrease number of API calls for file service you can add CDN, please check out the following documentation Cache and CDN Integration - Backendless REST API Documentation
Hello, I unfortunately have to say that I am now a little frustrated about the decision to change the previous subscriptions to variable subscriptions. We havenât been around that long and after a short time we already had our first price increase. Mark then quickly answered me that it was the first increase in 7 years and I can understand that, but it was annoying that I communicated the annual costs in our company and I had to quickly correct that.
Now the subscriptions are changing again. Since we have an annual payment, although only next year in April, it is still a second increase, but this time the increase will be significantly higher. According to the analytics data, we would then have to report a five-digit sum annually. We can certainly still optimize so that we can bring the total down a little, but the increase will still be significant. I transfer a lot of data from our local database to the backendless and there are a lot of API accesses because a lot of new data is generated every day. As an example, delivery note data is generated every day, which is then available in the app.
I will try to optimize as much as possible and distribute the access more. Currently they are all being played over one after the other at night.
I also generally welcome a new subscription like this, because if you use more resources, you should pay more, but the increase over the previous costs is really immense for us.