We have a proprietary profiler that is able to collect the right type of file given the health condition of your computer at the time. That saves a great deal of time as well as ensures that our process has the correct diagnostics the first time an issue happens in order to get the root cause of your issues.

We offer a run-time analysis, diagnosis and code fix service that slipstreams into development team's existing scrum process. We offer PRs containing performance-oriented code fixes that your team can release to resolve production performance problems.

Our current offering is targeted at production-only environments. If you wish you run the profiler in lower environments, please Contact Us.

One of the easist ways to identify performance issues is to look at the Time to First Byte of the page. The same metric exists within Application Insights as Response Time. This gives you a sense of whether there are performance issues with the webpage.

Regular bugs are typically quantitive in nature. Many of them which result in exceptions, the root cause of this are fairly easy to identify and resolve. Performance bugs are qualitative. They require a different set of tools to idenfity, at run-time, overconsumption of resources. After identify the type of resources being overconsumed, the cause must be identified and fixed.

The main measurement is TTFB or Response Time. That one measurement has many side effects, including drastically lowered conversion rate, lowered average cart size and increased bounce rate. You can use your average Response Time to determine what you may be able to reduce that number by. So, if your average response time on PLP, PDP, Cart and Checkout are 1.2 seconds, you may be able to reduce it by 400-600ms. That number will help you extrapolate your potential revenue increase.

Again, lots!

An Application is an executable for any number of purposes. This can be a console application, a Windowed application or a web application. For licensing purposes, whether you are using an Applicaiton or an API makes no difference. For licensing purposes, an API is an Application.

An Application is an executable for any number of purposes. This can be a console application, a Windowed application or a web application. For licensing purposes, whether you are using an Applicaiton or an API makes no difference. For licensing purposes, an API is an Application.

An API is an Application Programming Interface. Applications and APIs are considered under the same umbrella from a licensing perspective. i.e. They are both Applications.

An environment constitutes the server and software that renders a website. e.g. You may have 3 Environments, one for Integration, one for Preproduction and one for Production. Integration is a location where your code that has been under development is integrated and tested. Preproduction is a location where your code is hardened prior to being released to Production.

A computer which hosts an Application for a given Environment.

Cores as it relates to licensing is the aggregate number of cores across all servers running an Application for a given Environment. e.g. If you have 1 Environment with 10 Azure App Services with 4 cores each, you have an aggregate of 40 Cores.

This is the total lines of code for your code base. You can utilize the script we utilize to calculate the lines of code within a solution.