Category: web

Will SPDY Solve Web Application Performance Issues?

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.

see 3 comments

TCP and HTTP Improvements

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.

see 1 comments

Why TCP and HTTP affect web application performance

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.

add comment

Free webinar: TCP, HTTP and SPDY

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.

see 1 comments

Get the right troubleshooting tools for the job

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.

read more see 9 comments

WAF musings ... not again?

Following my obituary for Cisco’s WAF, Packet Pushers did a really great WAF-focused podcast with Raven Alder, appropriately named Saving the Web with Dinky Putt Putt Firewalls. If you have more than a fleeting interest in protecting business web applications, you should definitely listen to it. Just as an aside: when they were recording the podcast, I was writing my To WAF or not to WAF post ... and it’s nice to see we’re closely aligned on most points.

There’s just a bit I’d like to add to their ponderings. What Raven describes is the “proper” (arduous, time-consuming and labor-intensive) use of WAF that we’re used to from the layer-3/4 firewalls: learning what your web application does (learning because the design specs were never updated to reflect reality) and then applying the knowledge to filter everything else (what I sometimes call the fascist mode – whatever is not explicitly permitted is dropped).

read more add comment

Interesting links (2010-08-14)

A few days ago I wrote that you should always strive to understand the technologies beyond the reach of your current job. Stephen Foskett is an amazing example to follow: although he’s a storage guru, he knows way more about HTTP than most web developers and details of the web server architecture that most server administrators are not aware of. Read his High-Performance, Low-Memory Apache/PHP Virtual Private Server; you’ll definitely enjoy the details.

And then there’s the ultimate weekend fun: reading Greg’s perspectives on storage and FCoE. It starts with his Magic of FCoTR post (forget the FCoTR joke and focus on the futility of lossless layer-2 networks) and continues with Rivka’s hilarious report on the FCoTR progress. Oh, and just in case you never knew what TR was all about – it was “somewhat” different, but never lossless, so it would be as bad a choice for FC as Ethernet is.

Last but not least, there’s Kevin Bovis, the veritable fountain of common sense, this time delving with the ancient and noble art of troubleshooting. A refreshing must-read.

see 2 comments

To WAF or not to WAF?

Extremely valid comment made by Pavel Skovajsa in response to my “Rest in peace, my WAF friend” post beautifully illustrates the compartmentalized state some IT organizations face; before going there, let’s start with the basic questions.

Do we need WAF ... as a function, not as a box or a specific product? It’s the same question as “do we need virus scanners” or “do we need firewalls” in a different disguise. In an ideal world where all the developers would be security-conscious and there would be no bugs, the answer is “NO”. As we all know, we’re in a different dimension and getting further away from the heavens every time someone utters “just good enough” phrase or any other such bingo-winning slogan.

It’s popular to bash IT vendors’ lack of security awareness (Microsoft comes to mind immediately), but they’re still far ahead of a typical web application developer. At least they get huge exposure, which forces them to implement security frameworks.

read more add comment

Rest in peace, my WAF friend

A few years ago, Cisco bought a company that made application-level firewalls, first an XML-focused product (XML Gateway) that was also able to verify your XML data, later a Web Application Firewall (WAF), which was effectively the XML product with half of the brains ripped out.

I was really looking forward to these products. Layer-3 firewalls cannot protect web sites against application-layer problems like SQL injections or cross-site scripting, so we definitely need something on the application layer and the WAF (and XML Gateway) ran as virtual appliance in VMware, making them ideal for my lab environment. I quickly lost interest after the first cursory contact with the XML Gateway as you could only manage both products with a web-based GUI (and I definitely don’t want to publish blog posts full of screenshots).

read more see 6 comments

Netflix summary

Many thanks to those of you that responded with Netflix details (special thanks to Volcker for sending me the packet capture). Immediately after someone mentioned firewalls, I knew what the most sensible answer should be: to get across almost anything, use HTTP. No surprise, Netflix chose to use it. However, they’ve managed to deploy streaming video over TCP, which is not a trivial task. So, how did they do it?

read more see 2 comments