- Introduction
- WANem Setup
- Route the Traffic Through WANem
- WANem in Action
- Summary
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
WANem in Action
I've used WANem to test alleged performance problems from the U.S. west coast to one of the websites with which I've been involved. I started WANem on one of the workstations in my LAN and used the IBM Page Detailer on another workstation to measure the website's performance. I timed the round-trip time (RTT) to the U.S. west coast by pinging www.stanford.edu, getting an average RTT of approximately 180 milliseconds. The delay I entered in WANem was thus 90 milliseconds (half the RTT), and I selected a T1 link.
The first test, performed without WANem, established the baseline. The home page of the website would load in 3.5 seconds when accessed locally (see Figure 4).
)
When the 180-millisecond RTT was introduced, the web page became awfully slow (no wonder—more than 120 items had to be loaded) and took almost 30 seconds to load (see Figure 5). Point proven; time to go back to the drawing board.
)
After doing these tests, I started worrying about our company's Web 2.0 application servers. The blog (running on WordPress) did remarkably well: With an empty browser cache, the page loaded in two seconds (see Figure 6). Not bad for a transatlantic visitor.
)
MediaWiki is not so optimized; it took almost seven seconds to load the first page of our wiki, primarily due to several JavaScript libraries and numerous CSS files (see Figure 7).
)
Proper implementation of caching in MediaWiki and a fine-tuned Apache server resulted in significant improvement on second access. As the browser fetched only the HTML page (everything else was cached), the response time went down to less than two seconds (see Figure 8).
)