Web application load testing is different from website load testing because it targets a more complex environment. Web applications are comprised of highly sophisticated architecture where web servers must make requests of application servers that run custom coded programs. These application servers in turn make requests of database servers which store information about credit cards, product catalogs, airline schedules, user profiles, historical usage patterns, etc.

Web applications still deliver HTML pages to browsers for users to view, however those pages are created on the fly after the request comes in. They allow user input to be submitted through web form elements embedded in the page markup.

More on application architecture.

Load testing simulates a number of concurrent users moving through a web application or clicking around on a website.

Web apps differ from client server computing because with client server each application must be separately installed on each user's machine. C/S apps have their own UI built into a client program. I remember back in those old days when we had to figure out how to manually upgrade all those PCs sitting on desks at customers thousands of miles away. It was so much easier to deliver web applications, so we started building nothing but browser-based apps in 1999. It's cheaper, easier, and more stable.

Web load testing usually requires a tool that can generate large amounts of users taking certain actions against a target domain or set of servers. The objective is to measure the volume in metrics such as requests per second, concurrent users, or throughput of data (bandwidth consumed). Under heavy load, web servers will start to return status codes indicating errors are occurring. For instance, when the web system gets overwhelmed it may begin returning status codes of 500 (Internal Server Error). This indicates that all the processes building dynamic pages for the website are not getting the job done.

The web server gets the request and processes it to determine which html document is needed. In a typical web application, database queries are triggered to get user-dependent data in order to construct the response. Images, stylesheets, Javascript libraries, XML files, as well as custom html are pieced together by the application layer before it is returned through Apache or IIS.

A good overview from IBM's site:
In an interview for Wired magazine, Steve Jobs, of Apple, Inc., observed that the Web is moving through several stages of evolution. Stage zero represented the most primitive state of the Web, wherein most sites were document-centric and essentially static. With the coming of scripting and then Java applets, the world moved to stage minus one -- a step backwards, because many naive projects used these technologies initially for little more than "eye candy." Most reasonable organizations quickly grew out of that stage and into stage two, wherein the client and the server were made smarter. This meant evolving mechanisms to link the user experience to databases in the back-end, essentially starting to make every application accessible through a browser. Today, we see many sites moving to stage three, with greater semantics attached to data (in particular, via XML) and with greater exploitation of the potential of distributed computing. Stage four is likely to occur as agent technology matures and as mechanisms for pervasive distributed computing (such as Jini) become more stable.