Deef is spot on. You can signup @ http://newrelic.com/azure, after that you just click on your account name in the upper right corner, choose "account settings" and you'll find your license key on the right.

Then in the azure portal, under your WebSite >> Configuration >> Developer Analytics choose "custom" | New Relic as the provider and then paste your license key in the provider key field and "save"

A little more footwork than if you were able to go through the store but it will net you the same result.

We continue to improve the user experience with Azure engineering. Should you have any issues through the store at all, please visit us at www.newrelic.com/azure. Also, feel free to shoot us a note to our Partner Response Center, prc@newrelic.com. We'll make sure you get all the support you need to get up and running with New Relic.

We are using New Relic since couple of month. When I'm using dashboard I can see a method called application begin request takes a lot of our cpu and tones of weight lifting.. we want to trace it even further to go and check which part of our code is really causing this issue.

And it happen only when we deploy the app on azure instance and only at app-pool warm-up process for the application. I understand we can do use other custom file based logger to write individual timestamp. -Just wanted to know if new-relic can help up to investigate?

The BeginRequest slowness is sometimes related to thread agility or thread locking issues. Given that it only happens for you when you deploy / on warm it's most likely related to the startup of the ASP.NET process and JIT compilation.

The New Relic .NET Agent works by leveraging the CLR profiling API. When a profiler is attached, the CLR will JIT compile all methods in the .NET Framework when they are first used. This is different from normal runs where precompiled versions of the .NET Framework libraries are used in order to optimize application startup times. This cost is is something that will generally occur once per process, plus a little bit per application domain (Web Application for IIS). As the process is spinning up for the first time much of the JIT compilation for the application will probably happen at that time.

Normal warm up delays, though, is one of the reasons Microsoft introduced Application initialization in IIS. Since you cannot configure native modules (like Application Initialization) on Azure Web Sites they have provided a way for us to be able to gain some of the benefits "warming" through the always on configuration in Azure Websites.

Other than that you can always use the normal set of things to help speed up the loading of your Web Application (regardless of it being an Azure Web Site like): enabling compression, enabling caching, minify your JavaScript and CSS and so on.

Remove this comment

Remove this thread

Comments Closed

Comments have been closed since this content was published more than 30 days ago, but if you'd like to continue the conversation,
please create a new thread in our Forums, or
Contact Us and let us know.