NET 6 API with 3 endpoints:Įach endpoint has a different performance issue and the problems are pretty self-explanatory.īut first of all, we need to deploy the app into AWS ECS Fargate with dotnet-monitor as a sidecar container. The application I’m going to use is the same one I used on my previous post. For example, collect a CPU dump when you have a sustained high CPU during a period of time.
/livemetrics: Captures live streaming metrics of a process./metrics: Captures a snapshot of metrics of the default process in the Prometheus exposition format./trace: Captures traces of processes without using a profiler./gcdump: Captures GC dumps of processes./dump: Captures managed dumps of processes without using a debugger./processes: Gets detailed information about discoverable processes.It exposes an HTTP API for on demand collection of artifacts with the following endpoints: dotnet-monitorĭotnet monitor provides an unified way to collect traces, memory dumps, gc dumps and metrics.
#Fargate startup time how to
NET6 application on AWS ECS Fargate with dotnet-monitor as a sidecar container rather than how to profile an app.īut nonetheless after setting everything up on the AWS side I plan to briefly show you how to use the dotnet-monitor HTTP API to profile an app. This post is more oriented towards the necessary steps to deploy a. NET CLI diagnostic tools is doable but is an absolute pain in the ass.įargate is a great example where the dotnet-monitor tool becomes really handy when we want to profile a. Fargate is a serverless container platform, it is a general-purpose platform, which means it doesn’t have a specialized set of diagnostic tools put in place like Azure App Service, and trying to access a running container to execute the. Nonetheless there are some environments where collecting diagnostics can become cumbersome, for profiling an app in these kind of environments you can use the dotnet-monitor tool.ĪWS ECS Fargate is one of this environments. There are even some Cloud Services, like Azure App Services, that uses its own set of diagnostic tools, so you don’t need them at all. If you’re running on some sort of Kubernetes cluster you can bake them inside the docker image and afterwards connect to the pod using the kubectl command line.
#Fargate startup time install
If your apps are running on a VM you can add them on the base image or connect remotely to the machine via SSH and install them. Those tools (dotnet-counters, dotnet-dump, dotnet-gcdump and dotnet-trace) are designed to work in a wide variety of environments. In my previous post I talked about how to profile a. I’m pretty confident that everyone at some time or other has stumbled with an application that performs well on your local machine, maybe even on the dev environments, but when you put it on production it begins to perform poorly, and it becomes an ordeal trying to pinpoint the root cause of the problem.
#Fargate startup time code
As always, if you don’t care about the post I have uploaded the source code on my Github.
0 kommentar(er)
