Thanks for reading my question.
I 've deployed my gcr image to cloud run. The app is based on FastAPI and it has been built on cloud build with dockerfile.
I've set the number of minimum instance as 2 to avoid the cold start and set the CPU as always allocation.
The problem is the cloud run time varies.
The response time is sometimes 2 mins and sometimes 15 mins.
I can't know the reason when on earth it takes 2 mins and when on earth it takes 15 mins.
I am wondering this is the problem of internal system on Google cloud.
Please answer my question.
Related
I have read through most of the questions that seems to be similar to what I'll ask so hopefully I'm not wasting anyone's time.
We have a Function App in Azure Cloud that contains several Durable Functions.
One of these durable functions is a HTTP trigger API REST call.
It will normally take between 0.5 - 3 seconds to execute fully (from call to done, delivered result). But sometimes it takes 20-35 seconds. I don't know why or how I can search for errors.
The durable function fetches information from a Cosmos DB and delivers the result back to the caller.
Function App, Durable Function and Cosmos DB are all located in the same Region. (Checked that).
The Durable Function is set to B2:2 and has toggled Always On to ON.
Is there something I miss or something I should check to make sure it runs smoother?
Log of executions of the app:
I greatly appreciate everyone's time and energy they put into helping me. Thanks a lot.
---- Additions to the post after posting ----
I have checked the interactive tool and if I read that correctly it tells me a maximum execution time of 0.8 seconds and a maximum network lag of 6 seconds. That would indicate something that I suspected before I set up this post and that is that Azure needs to cold start the function. But I have always on toggled on so why?
It doesn't seem to take 30 seconds to complete the function. It seems to take less than 1 second to complete the function and up to a maximum of 6 seconds lag, but where are the other 23 seconds going in a 30 second call?
B2:2 is the service agreement I have with Azure. B2 is the test environments second paid state with 2 instances scaling (I have changed that to 3 after posting this).
Application Insights are on and no other dependencies are present except the Cosmos DB.
AFAIK in Azure Functions,
After 5 minutes of inactivity, Function App goes to the cold state. To come out of it, 10 seconds delay occurs.
Even the Function App is in Hot State, it will take some excessive amount of time to load the external libraries defined in it.
In the Function App, Code Logic Performance also matters the cause of slowness in the Azure Functions.
There are few steps for reducing the cold-start times particularly for the Functions having external libraries:
Running from a package file WEBSITE_RUN_FROM_PACKAGE to 1 may reduce cold-start times, particularly for JavaScript functions with large npm package trees.
From the Azure Portal > Diagnose and solve problems > Troubleshoot Performance category to identify the causes of slowness:
Try Always On Feature available in App Service Plan and Premium Plan of the Azure Functions to prevent such issues.
Regarding the Performance and reliability improving of Azure Functions, please refer here.
If this issue persists still, then please raise an incident with Microsoft Support to get the root cause and resolution.
Try fiddling around with maxqueuepollingintervall. It helped out with our cold starts quite a bit.
If I have 5 bots for trading and a along with this a script that does some updating on prices using scraping. All these files uses Node js. Now, I was able to deploy all the 6 scripts on digital ocean, but due to 6 scripts running together as 6 different processes the CPU usage in even their most expensive plan became 100%. Then I decided to shift to google cloud. But it turns out with GPU it is hell expensive.
Essentially what I want to do is that run the 6 scripts at 3 distinct times in a day for 10 mins. Other than those particular times the 6 scripts do nothing.
I have set a file named concurrently.js that runs all these scripts using the command concurrently.
Is it possible to run concurrently.js at 3 particular times of the day and then after 10 mins when the job is done, shut down the virtual machine?
Say machine turns on at 12.00pm then the 6 files work for 10 mins and then the machine shuts off at 12.10 pm. And then turns on at say 3.05 pm and so on.
If I can schedule on and off of the VM I can afford google cloud.
I got to know about cron and google cloud scheduler, but they need an App url to schedule tasks. But I don't have an app url because I don't have app only, I just want to run the concurrently.js file present in the virtual machine along with other files, can I do the scheduling?
Any help is highly appreciated!!!
You can do this with Google Cloud. Here the process
Cloud Scheduler start your Compute Engine VM
At startup, the Compute Engine VM runs a startup script that run your process
At the end of the process the VM auto shutdown
So for that you need to
Call the Compute Engine start API
Set a startup script on your VM
Shutdown the VM automatically at the end of the processing
If you are stuck in one step, let me know, I could narrow my help.
So i wrote a node script which fetches data from WP.org themes/plugins. The theme script will take around 4-5 hours to complete ( scraping and inserting data into BigQuery ).
The problem arises when i used google app engine to deploy the script, it works fine for 15 mins then it stops. Any way to increase the execution time of scripts in app engine.
These scripts will run weekly or every fortnight and will run until they are done. But app engine stops them after 15 mins. They works fine on my localhost so its not issue with node.
The max allowed run-time of a request is based on your selected scaling type. So it sounds like you will need to create a separate service to run this task with Basic or Manual set for the scaling type
https://cloud.google.com/appengine/docs/standard/nodejs/how-instances-are-managed#scaling_types
You could also try breaking up your task into multiple 10 minute tasks and chain them together
I'm using Azure REST API to create, deploy and start a Cloud Service (classic) (cspkg hosted in Azure Storage) with hundreds of instances. I'm noticing that time Azure takes to provision and start the requested instances is really heterogeneous. First instances might start in 6-7 minutes but last ones might take up to 15-20 minutes, about 10 minutes longer than first ones. So my questions are:
Is this the expected behaviour? If so, what's the logic behind this? Could I do anything to speed things up?
How is Azure billing this? Is it counting the total count of instances since the very initial time when Cloud Service is deployed? or is it taking into account the specific timing on each individual instance?
UPDATE: I've been testing more scenarios and I've found a puzzling surprise. If I replace all the processes that my Cloud Service instances should run by a simple wait for some minutes (run .bat file with timeout command) then all the instances start almost at the same time (about 15 seconds between fastest and slowest instance). It was not just luck and random behaviour, I've proved that this behavior is repeatable and I can't even try to explain the root reason.
I also checked this a few weeks ago, and the startup time, depends on the size of the machine, if it is large it has more resources, so the boot time is faster, and also, if there is any error, exception on startup the VM will recycle till it can successfully start. I googled it, but did not find any solution to speed this up, so I don't think it is possible to do anything about the startup time. In the background every time when you deploy something, it will create a Windows Server, and boot it up and deploy your package on it and puts your web roles behind load balancer, this is why it takes so long, because a lot of things are happening.
The billing part is also not the best for the classic cloud services, you have to pay for it even during the startup and recycle, and even when it is turned off, so if you are done with your update, you should delete the VMs from your staging slot or scale it down, because you will pay for it even if it is turned off.
I’m about to start work on an API that will literally go from 0 RPS to a couple hundred thousand HTTP RPS at the same time and run at that rate for ~2 mins. All processing of those 30 million requests must finish by the end of that 2 min period. This would happen 7 times a WEEK.
Going serverless with Azure Functions in Consumption Plan Hosting Mode sounds appealing. This document describes that a scale controller exists to coordinate app instances, but doesn't really discuss what I can expect from it for HTTP triggers. I can’t find any info that says the scale controller will be able to respond in the time frame I'd need.
The best info I could find was this info saying it took nearly 8 mins to scale up for his tests.
Is this a bad use case for Azure Functions in consumption mode?
Obviously, spinning up a testing harness that is capable of issuing 30 million requests within 2 minutes is an undertaking of its own, and an expensive one. I'd like to learn from others who have already done so.
Based on my experience, this scenario is not properly covered by Consumption Plan. They can scale up to many instances, but not very rapidly. 2 minutes is way too fast to rely on.
I was mostly working with queues, not HTTP, but I got delays up to 40 minutes caused by low pace of scaling up.
If you can predict which 2 minutes are going to be heavy-loaded, your best bet could be to provision the capacity with a script (or another Function).