Welcome!

Machine Learning Authors: Pat Romanski, Elizabeth White, Yeshim Deniz, Zakia Bouachraoui, Liz McMillan

Related Topics: Microservices Expo, Java IoT, Linux Containers, Machine Learning , Agile Computing, @DXWorldExpo

Microservices Expo: 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.


CloudEXPO Stories
The challenges of aggregating data from consumer-oriented devices, such as wearable technologies and smart thermostats, are fairly well-understood. However, there are a new set of challenges for IoT devices that generate megabytes or gigabytes of data per second. Certainly, the infrastructure will have to change, as those volumes of data will likely overwhelm the available bandwidth for aggregating the data into a central repository. Ochandarena discusses a whole new way to think about your next-gen applications and how to address the challenges of building applications that harness all data types and sources.
Lori MacVittie is a subject matter expert on emerging technology responsible for outbound evangelism across F5's entire product suite. MacVittie has extensive development and technical architecture experience in both high-tech and enterprise organizations, in addition to network and systems administration expertise. Prior to joining F5, MacVittie was an award-winning technology editor at Network Computing Magazine where she evaluated and tested application-focused technologies including app security and encryption-related solutions. She holds a B.S. in Information and Computing Science from the University of Wisconsin at Green Bay, and an M.S. in Computer Science from Nova Southeastern University, and is an O'Reilly author.
CloudEXPO New York 2018, colocated with DevOpsSUMMIT and DXWorldEXPO New York 2018 will be held November 12-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI and Machine Learning to one location.
CloudEXPO | DevOpsSUMMIT | DXWorldEXPO are the world's most influential, independent events where Cloud Computing was coined and where technology buyers and vendors meet to experience and discuss the big picture of Digital Transformation and all of the strategies, tactics, and tools they need to realize their goals. Sponsors of DXWorldEXPO | CloudEXPO benefit from unmatched branding, profile building and lead generation opportunities.
ICC is a computer systems integrator and server manufacturing company focused on developing products and product appliances to meet a wide range of computational needs for many industries. Their solutions provide benefits across many environments, such as datacenter deployment, HPC, workstations, storage networks and standalone server installations. ICC has been in business for over 23 years and their phenomenal range of clients include multinational corporations, universities, and small businesses.