Category: Web

The first batch of the latest materials for my Designing Scalable Web Applications course have been published on my free content web site.

An odd idea stroke me when watching the Avalanche NEXT presentation during Networking Tech Field Day – they have a fuzzing module that you can use to test whether your servers and applications survive all sorts of crazy illegal requests. Could that be used to detect SQL injection vulnerabilities in your web apps?

If you’ve ever tried to troubleshoot web application performance issues, you’ve probably seen it all – browser waterfall diagrams, visual traceroute tools, network topologies produced by network management systems … but I haven’t seen them packaged in a comprehensive, easy-to-use and visually compelling package before. Welcome to ThousandEyes.

In the TCP, HTTP and SPDY webinar I described the web application performance roadblocks caused by TCP and HTTP and HTTP improvements that remove most of them. Google went a step further and created SPDY, a totally redesigned HTTP. What is SPDY? Is it really the final solution? How much does it help? Hopefully you’ll find answers to some of these questions in the last part of the webinar.

In previous videos from the TCP, HTTP and SPDY webinar I described the network-related performance challenges experienced by web applications and did a deep dive into TCP and HTTP mechanisms underlying them.

Today’s video describes numerous TCP and HTTP enhancements – from increased initial congestion window (recently published as RFC 6928) and TCP fast open to persistent HTTP sessions and pipelining.

The deep dive into TCP and HTTP mechanisms that impact web application performance triggered numerous questions during the live webinar session – it took me almost 10 minutes to answer them all.

In the first part of the TCP, HTTP and SPDY webinar I explained why TCP and HTTP impact the end-to-end web application performance. In the second section of the webinar, we did a deep dive into the actual TCP and HTTP mechanisms that increase end-to-end latency (3-way handshake, initial congestion window, request/response nature of HTTP).

In the ideal world, you’d get a new web page within 100 milliseconds of clicking an active web page component (link, button ...). Reality is way harsher – sometimes it takes seconds till you can enjoy a web page served from a well-behaved web server (let’s pretend there are no server performance issues).

In the first part of my TCP, HTTP and SPDY webinar I explained how the transport mechanisms (TCP and HTTP) impact the end-to-end web application performance and what you could do to reduce the web page loading time.

Most web application developers remain blissfully unaware of the major performance roadblocks their applications face in the wild: access network bandwidth restrictions and unexpectedly high latency (see also Fallacies of Distributed Computing with an in-depth explanation). The impact of these two roadblocks is further amplified by behavior of TCP and HTTP, the protocols used by almost all web applications.

These issues are well documented in my Scalable Web Application Design course and in a free TCP, HTTP and SPDY webinar for those of you who won’t be able to make it to Ljubljana.

A while ago Matthew Norwood wrote an excellent article describing the troubleshooting process they used to figure out why a particular web application worked way too slowly. Greg Ferro was quick to point out that it doesn’t make sense to assume the network is the problem and work through the whole chain slowly eliminating every potential networking device as the source of the problem when you might be facing an application design issue. However, there’s an even more important consideration: your network troubleshooting toolbox lacks the right troubleshooting tools for this job.