Welcome!

Linux Authors: Jason Bloomberg, Roger Strukhoff, Liz McMillan, Elizabeth White, Pat Romanski

Related Topics: SOA & WOA, Java, Linux, AJAX & REA, Web 2.0, Big Data Journal

SOA & WOA: Article

Love or Hate Flash?

Here’s how to use web server content compression properly

Are you serving .SWF files from your web server and getting complaints from your end users that your flash app is "just slow?" Or has your Ops team wondered why you see such high web request response times for some of the web service calls executed by your Flash Client?

I was just working with a bank that uses a Flash Component for one of their internal risk management applications. For years they wondered why users were complaining about very slow response times when executing, e.g., a "Credit Worthiness" check. Our teams helped them figure out the root cause of the performance problem: "Back in the day" they had turned off Apache's Content Compression (MOD_DEFLATE) in order to avoid a known issue of content compressed flash files that are content compressed. Unfortunately they turned it off completely and not just for .SWF Files. So - all other requests - especially the heavyweight Web Service Responses were not compressed.

After selectively turning on content compression they are now seeing a 50% improvement in overall response time; 70% reduction in Apache and a 92% reduction in transferred bytes. Here's how they analyzed and solved the problem:

Step #1: Identify the Slow Requests
Looking at the captured PurePaths it was easy to spot that most of the time (2/3) was actually spent in the Web Server and not in the App Server:

8.1s alone are spent in the Web Server to send the content from the App Server back to the End User

But why 8.1s? That's a long time spent for mainly just I/O (e.g., reading and writing to the network). Looking at the request details shows us that not only did this call come from a Flash Component (Referrer Header) but that the response size of that request was 2.25MB. As this web request is called very frequently and other requests also tend to have a very large response body, network bandwidth becomes a problem, which results in lots of time spent in I/O when sending back the content to the browser:

2.25MB in Response Size is the driving factor for the slow web server response time

For steps 2 & 3, and further insights, click here for the full article

More Stories By Andreas Grabner

Andreas Grabner has more than a decade of experience as an architect and developer in the Java and .NET space. In his current role, Andi works as a Technology Strategist for Compuware and leads the Compuware APM Center of Excellence team. In his role he influences the Compuware APM product strategy and works closely with customers in implementing performance management solutions across the entire application lifecycle. He is a frequent speaker at technology conferences on performance and architecture-related topics, and regularly authors articles offering business and technology advice for Compuware’s About:Performance blog.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.