|
Razor Profiler is a browser-based tool that automates JavaScript profiling.
Why Razor Profiler?
The amount of JavaScript code on the client side is increasing significantly with the growing popularity of Ajax and Web 2.0.
Web developers rely on JavaScript heavily these days in order to deliver a richer user experience.
Including a either home-grown or third party JavaScript library and application specific code, today's web applications can easily have several thousand lines of JavaScript code, or even tens of thousands of lines.
The footprint of client side JavaScript
can range from tens of kilobytes to hundreds of kilobytes. This amount of JavaScript can do magic to application functionality and user experience, but they also introduce many questions.
As an application developer:
- How do you measure the runtime behavior of your code on the vast array of client platform and browser combinations?
- Do you know why the same code works well on one browser but performs very poorly on a different browser?
- Do you know whose code is causing problems, yours, or a third party library?
- Do you know exactly where is the performance bottleneck?
If you are a JavaScript library developer, it is even more important for you to understand the runtime behavior of your code since that it will be used by other developers in many different ways.
However, there is no easy way to obtain the answers to the above questions. It is difficult to study the runtime behavior of Javascript applications in a cross-browser environment:
-
Different browsers (Internet Explorer, FireFox, Safari, etc) have different runtime behaviors. The same code can behave very differently on different browsers;
-
Lack of tooling that supports JavaScript debugging and profiling. JavaScript has evolved from being perceived as a "toy language" to be a heavily used mainstream programming language for writing web applications, but JavaScript tooling has not caught up yet;
Razor Profiler aims to help solve this problem. Razor Profiler is JavaScript profiling tool
that aims to make it really easy for web developers to profile their Ajax code in a cross browser
environment.
Razor Profiler Features
Razor Profiler automates JavaScript profiling:
-
Automation: no application code change required. Razor Profiler automatically collects all the necessary data and presents them to web developers for analysis.
-
Runs on any browser: web developers can profile any JavaScript application on any browser. There is nothing to install on the client side.
-
Rich lexical analysis: Razor Profiler presents rich lexcial information about the application, such as file information (number, response status, size, mimetype, percentage, etc),
tokens (size, file, percent, count), and functions (size, file, name...), etc;
-
Profile scenario recording: Razor Profile enables web developers to selectively record the scenarios that they are interested in. Only recorded scenarios will be used in analysis.
-
Call stack analysis: for each recorded scenario, Razor Profiler presents all the call stacks in the order of their occurence. For each call stacks, web developers can drill into it to find out
the duration of the stack, all the function calls of this stack and the duration of each call.
-
Function analysis: For each JavaScript function in the application, Razor Profile presents the number of times it has been invoked, the duration of each invocation, and the call stacks that invoked this function.
-
Data visualization with graphing and charting: Razor Profiler presents top call stacks, top function calls of each stack, top recorded scenarios, etc. using visual charts and graphs to help web developers
better understand the runtime behavior of their application. For example, each call stack is visualized as an intuitive Gantt chart.
some Razor Profiler screen shots are available here.
How Does Razor Profiler Work?
Razor Profiler composes of a server component that runs inside a standard Java EE Servlet engine, and a JavaScript-based client component that runs inside any browser. Once you have Razor server started, you can profile your JavaScript application by entering the start URL of your application into Razor Profiler and run through your test scenarios.
Razor Profiler will automatically record data and visualize them for your analysis. There is no client side installation, browser configuration change or application code change required.
In order to achieve this, Razor Profiler goes through five different phases:
- Application retrieval: Once a web developer enters the application start URL into Razor Profiler, Razor Profiler client component ("the client") will send this URL to Razor Profiler server component ("the server").
The server performs the actually retrieval of this URL. After additional server processing (such as lexical analysis and code injection, see below), the retrieved content is sent to the client side to be displayed in a new browser window. For the developer point of view, the application is launched and running
in this new browser window.
In this process, Razor Profiler Server is acting like a "proxy server". But it is not really a "proxy server" and there is no need for developers to re-configure their browser proxy settings.
- Lexical analysis:
Once the server retrieves the application URL, it performs lexical analysis of the returned content by identifying and analyzing JavaScript files, functions, and tokens,etc. The result is sent to the client
for display.
- Code injection: Upon lexical analysis of JavaScript code, the server injects "probe" code into the application's JavaScript sources before returning them to the client. These injected "probes" enable
automatic collection of application runtime data, and saves developers from doing so manually.
- Runtime data capture: Once the application's JavaScript code is running on the client side and as developers run through desired profile scenarios, the injected "probes" automcally
collect all the necessary data to Razor Profiler Client.
- Data analysis: When the developer finishes recording scenarios and starts data analysis, Razor Profiler client performs analysis of all the collected data and presents the results.
How To Get Razor Profiler?
Just go to http://www.razorspeed.com
and download it. Follow the installation instructions to install Razor Profiler server. Or, you can try it online as an online service.
How To Use Razor Profiler?
You can use Razor Profiler either online as a service
or download it to run on your local server. You can download it from here to run on your local server.
-
Start Razor server if you want to run it locally;
-
Launch a browser, enter the URL of your Razor Server instance to launch Razor Profiler. Given that Razor Profiler is required to be installed as the "ROOT" application
of the Servlet engine, Razor Profiler URL should be something like http://server:port/, where "server" is the hostname or IP address of the machine where Razor server is running, and
"port" is the port number that the servlet engine is listening to.
-
Click "New Session" and enter the start URL of your application.
-
If you want to profile the initial application loading and startup, make sure the checkbox "Record application initial loading profile data" is checked. Otherwise uncheck it;
-
Note: you must disable popup blocker because Razor Profiler needs to display your application in a new browser window;
-
Your application will be launched in a new browser window. Just go ahead and run your application through desired scenarios like a normal user. As you run your application, Razor is recording profile data in the background;
-
After you finish your profile scenarios, go back to the Razor browser window, click "Stop Recording" to stop recording. Afterwards, you can either click "Record Profile Scenario" to record an additional scenario, or click "Close and View Results" to analyze collected data.
Note: In order to profile an application, the application must be HTTP accessible from the Razor Server instance that you are using.
|
Can you give me a hand with this?
Thanks in advance.
Is your razor server running behind a proxy server? Can you post some more details of the problem you see (stack trace, console output, etc)?