on our shared server app (id: 1B92F985-D9EF-9689-FFAC-C7E5FE5F2A00) there is error message in console:
"Your application has exceeded a limit of the undefined on the current plan.
All API calls are now blocked until the limits are increased.
"
I believe this is due to Business Logic scripts size, which on payment plans stated have now 21mb, whereas limit is 20.
However, when I quite aggressively decreased size down to 8 mb - I still can’t deploy and while try deploy I only got error “… the application has been blocked due to exceeding the limit”
Hi Yuriy,
The apps are usually unblocked automatically in 2-4 hours after you have decreased the usage. We’ve unblocked it manually just now to speed it up. Please verify if everything is fine now.
hmm, but how system allowed to deploy 21mb with 20mb limit? Also how would it be unblocked after decreased usage if it didn’t allowed to “npm run deploy”? I guess, I had to remove some files via developer console “coding” section?
also - isn’t there option to increase BL size to more than 20 mb (that’s way too low in the world of current bloated node_modules)?
The limit is typically not checked while you use the service, since the check itself noticeably increases the response time (because interactions with our billing provider to retrieve the limit are required).
There is an external service which checks the usage and limits periodically. It blocks and unblocks the app depending on the comparison of the usage and limit.
So if you correct the usage in your app to be within the limits (regardless of how you do that - either via redeploying or by removing files manually), that service will unblock your app on the next periodic check (which is 2-4 hours usually, but that may vary a bit).
There’s no way to increase the limit further. We came up with this number to prevent users from unintentionally slowing down their services, since the JS CodeRunner loads up all these modules each time the business logic script executes. We can’t keep the process permanently running because it would be too resource-consuming considering the number of apps in the online version. Though we’re in the process of creating a cache layer which would greatly improve this for active apps.
I’d be happy if you shared what would be the reasonable higher limit as to your opinion, considering the constraints described? Probably we may discuss a change if we see it’s really needed.
Well, I wasn’t aware of “slowing down their services, since the JS CodeRunner loads up all these modules each time the business logic script executes”, what kind of slowdown are you talking can you provide some numbers (like “+100ms for each +1mb”).
The node_modules are known for their bloated size. We aren’t using much modules (md5-hash, paypal-rest-sdk, request, web-push, xml2js) and it’s already 8mb (after some manual junk removal from node_modules). 21mb when there were few modules for logging libraries, sms sending lib (and before manual node_modules unnecessary files removal).
Maybe you can keep some of the most common modules (https://www.npmjs.com/browse/depended) available in some kind of “shared environment” so it doesn’t counted?
We did not measure the dependency between the code size and time it takes to load it, but loading files from the file system (which nodejs does to execute them) is known to be slow and we run into that on one of our customers’ project where CodeRunner had to handle lots of requests per second.
Typically this problem is negligible, because most nodejs server do not run on-demand, so the overhead is only one-time. But in our case each request runs a separate nodejs command and the file loading time is added to each request.
By the way, our documentation has an advice on how to keep your node_modules smaller by only saving what you actually use:
To reduce the deployment size, consider minimizing the installation of the dependencies to only what the code needs. For example, since the code above uses only the camelCase function, it is possible to install only that module as shown below:
npm install lodash.camelcase --save
Then use the module as:
var camelCase = require('lodash.camelcase');
Backendless.ServerCode.Persistence.beforeCreate('*', function(req) {
req.item.name = camelCase(req.item.name);
});
As to the most common modules, actually we have a few built-in, including lodash, underscore, once, uuid, querystring and a few more. But I see this list is not documented, so I’ll pass this further to be added to the docs.
By the way, how can I check my Business Logic size after I’m done editing (adding new packages) without chance of triggering system block due to size limit? I mean, I know only one way to check size, after deploy (with “–keep-zip” key)
Indeed, there’s no option to check zip size before deploying. We’ve created a task (BKNDLSS-17225 for tracking purposes) to add a new option --size-confirmation, which will pause the deployment, print the total size to be deployed and ask whether you’d like to continue.
Hi Yuriy
We’ve fixed and released it, update JS CodeRunner to version 4.6.7
and run deploy with the next argument:
npm run deploy -- --zip-size-confirmation
Regards, Vlad
yup, that’s showing size, thanks!