Performance, Scalability and Architecture

Andreas Grabner

Subscribe to Andreas Grabner: eMailAlertsEmail Alerts
Get Andreas Grabner: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: SOA & WOA Magazine, AJAX and ContinuousAPM, Big Data on Ulitzer, Application Performance Management (APM)

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 been helping companies improve their application performance for 15+ years. He is a regular contributor within Web Performance and DevOps communities and a prolific speaker at user groups and conferences around the world. Reach him at @grabnerandi

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.