Andreas Grabner About the Author

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

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 heavy weight 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

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

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

Step #2: Configure Apache

After some internal and external research they discovered that their Apache didn’t use any content compression as it was turned off a while ago to prevent a problem with Flash Components. Turning it off completely, however, impacts every other request that is not downloading the .SWF file. In response, they went ahead and tested content compression for MIME-Types other than .SWF where content compression makes sense. In case you want to learn more about this check out http://httpd.apache.org/docs/2.4/mod/mod_deflate.html and pay special attention to the tips to exclude .SWF content types. This is also discussed on Stackoverflow and by Phil Chen on his blog about Mod_Deflate and Flash SWF.

Step #3: Verify Impact of Change

After the change was implemented, the performance impact was immediately visible:

Great improvement in response time but even more so on the transferred bytes. This saves lots of network bandwidth

Great improvement in response time but even more so on the transferred bytes. This saves lots of network bandwidth

Conclusion: Revisit your Settings from Time to Time

It is important to revisit and rethink your production environment settings. Just because these settings worked in the past doesn’t mean they still work. Even beyond production environments as a “DevOps Best Practice” you need to include developers, testers and operations in these discussions. Developers might be aware of special settings that can speed things up, testers can verify in staging and operations can tell them what the real life looks like.

Comments

*


8 − six =