ryochiji's blog

Analysis on Factors Affecting Web Application Performance

This summer, I'm supposed to be doing research on performance and IlohaMail, so I thought it would help to start by putting together my thoughts on web application performance in general. You see articles about optimizing this and that, but what makes performance optimization so complicated with web-apps is that there are so many factors involved. In my article, I identified five:

Execution Speed
Response Time
Interface Flow
Transfer Speeds
Rendering Speeds

Show Rest of Post

posted in Devel at 23:32* [927 comments | View | Add Comment ] [PermaLink] [Trackback]

Execution Speed - By "execution speed" I mean how fast the programs execute on the server. With web apps written in scripting languages (i.e. interpreted languages) there are a number of factors since all code is compiled on a per-request basis (unless there's a caching mechanism). One such factor is source file sizes (as a rule of thumb, the smaller the source file(s) the better). In fact, some PHP optimizers simply optimize the code by taking out unnecessary data (i.e. comments). Then, there's the actual performance of the algorithms used. I remember getting a huge performance boosts when I changed a O(N^2) algorithm with a O(log(N)) algorithm in one of the routines in my IMAP library. For processor intensive tasks, it might make sense to offload much of the data crunching to specialized external apps (preferably written in C/C++: BlogMatcher was one example where I did this and got huuuuuuuuge performance benefits). Finally, with apps that utilize external data sources (i.e. databases, mail servers, external web services), the performance of the overall system may ultimately depend on the performance of such external sources.

Response Time - By response time, I'm talking about the perceived delay before the user receives a visual response, after performing some action on a web app. The shorter the delay, the faster the app appears to the user. Note that response time doesn't necessarily take into consideration how long it takes for certain actions to complete, but rather how long a user has to wait before it appears to begin. Response time is actually very very easy to improve. All a web app has to do is return some output as soon as possible. Many browsers begin rendering as soon as it receives output from the server, so the user would receive visual feedback as soon as the server starts sending output. I've seen scripts out there that put together the entire output before sending it to the client. This might make it easier to write clean code, but this is detrimental to the app's response time, since the user does not receive any feedback until the entire script completes execution. On the other hand, if the app can send back some data before entering some of the slower processes, users will receive almost instant responses.

Interface Flow - Often times, the slowest process will be the user. If users can work faster, it will seem to them as if the overall system is faster as well. What this boils down to is good UI design. This is an entire field worthy of many a flame wars, but the two I personally consider to be the most important are spacial orientation and widget density. Spacial orientation allows users to locate widgets that they want by space, not by visual cues. Although most user interfaces depend on visual cues, interpreting and searching visuals (or worse, reading text) often takes longer than if you simply knew where something was. Widget density refers to how densely UI elements are grouped together. My rule of thumb is, the lower the widget density the better. There are a number of reasons for this. Firstly, a high widget density implies smaller widgets, and secondly, it implies that widgets are packed close together. Small widgets are bad (see Fitt's Law) and widgets that are closer together are more prone to user error. Also, when widgets are packed together, it's more difficult for users to develop spacial orientation (spacial orientation is, after all, a rough estimate and require a large buffer zone).

Transfer Speeds - What kills high-volume sites isn't the amount of traffic from, say, broadband users; it's the modem users that are deadlier. Slow connections take longer to download content, which means server resources are tied up longer. If your output is large, things will also appear slower on the client side since it'll take longer to download. So, it's in your mutual interest to keep your output as compact as possible (hint: look at Google's output. human readability goes straight out the window). Oh, and not having large graphics helps too. In fact, I'd say keep those pretty pictures to a bare minimum, especially for web apps. IlohaMail has virtually no images, yet I've heard nothing but good things because of that.

Rendering Speeds - Finally, with web apps, the output is obviously in HTML or some other markup language (and, possibly, some client-side code like JavaScript). Even if the server can send all this code back quickly, if the browser takes for ever to render it, the whole thing will appear slow. Keeping the HTML size small helps, but I'm sure some things take longer to render than others (like complex table structures).