Static vs. Dynamic Content

The difference between static and dynamic content

Static content are files that don't change based on user input, and they consist of things like JavaScript, Cascading Style Sheets, Images, and HTML files. They comprise the structural components of SAP BI web applications such as BI Launch Pad and the Central Management Console (CMC).

Static content never requires dynamic data, such as bttoken, and can be served equally well by an application server such as Tomcat, or with a web server such as Apache. Because there is a significant amount of static content in BI Launch Pad, it can clutter the JMeter interface.

Dynamic content requires processing by an application server such as Tomcat, and typically invokes backend services via the SDK. For example, logging on calls the logon.do method, which invokes the Central Management Server (CMS) for the user authorization process. Similarly, viewWebiReport.do engages a Web Intelligence Report Server in order to render a report.

Dynamic content almost always requires dynamic data such as bttoken and is what performs the actual business usage within BI4.

Is static content relevant to my test plan?

In order to determine whether or not static content is important to the success of your test plan, you must evaluate which components you are interested in testing, and what facets of the user experience are relevant.

For example, if your goal is to evaluate the maximum number of Web Intelligence reports that can be processed on a dedicated Webi Report server node, then static content might not be something you care about. If, on the other hand, your intent is to stress test the performance of your web tier components, static content might be a critical facet for you.

Keep in mind that static content is also cached on most client browsers after the first time it is accessed. This means that workflows you record should either be considered cache pessimistic (all static content is requested every time) or cache optimistic (static content is never requested as it is assumed users have previously accessed the system).

The decision is ultimately yours but one thing is certain, the elimination of static content makes the JMeter interface much less busy and enables you to quickly identify dynamic content calls when performing customization.

Eliminating static content from your test plan

Should you decide that your test plan does not require static content, eliminating it is a simple proposition. Since browser caching for static resources is enabled in BI4 by default, you simply need to "warm" the cache by performing your workflow from end to end one time prior to recording it with the HTTP Proxy component. By doing this, requests for static content will be served from your local browser cache and won't appear in the HTTP Proxy recording.

You will also want to ensure the setting Retrieve all embedded resources from HTML Files is not enabled on the proxy as this could still cause additional static content to be requested.

By "warming" the cache for the workflow used in Creating your First Test Plan the resultant captured samplers look like this:

Note the significant reduction in requests ... this reduces the number of requests in the Log On/Log Off workflow by almost 75%!

To ensure static content is collected, simply delete the browser cache or clear your temporary internet files prior to recording the test plan.