Website Monitoring NewsLatest posts and articles on website monitoring services.

Serial vs. Asynchronous Events

Many events oc­cur from the time the user in­i­ti­ates a re­quest to the time the re­quest is com­plete­ly ful­filled.  If all those events oc­cur one at a time, in or­der, each wait­ing for the pre­vi­ous one to com­plete, the to­tal amount of time re­quired to han­dle the user’s re­quest is the sum of the times of each of the events.  This is called ser­i­al pro­cess­ing, which is a form of syn­chro­n­ous pro­cess­ing.

If we can make mul­ti­ple events oc­cur at the same time, we can re­duce the amount of time re­quired to ful­fill the user’s re­quest.  This is the con­cept be­hind asyn­chro­nous pro­cess­ing.  To the ex­tent we do not over­tax sys­tem re­sour­ces, asyn­chro­nous pro­cess­ing de­li­vers bet­ter per­for­m­ance than ser­i­al pro­cess­ing.  Once we start over­tax­ing sys­tem re­sour­ces, though, asyn­chro­n­ous pro­cess­ing can ac­tu­al­ly de­li­ver poor­er per­for­m­ance, as de­mon­stra­ted in figure 4 of Per­form­ance Re­search, Part 4: Max­i­miz­ing Pa­ral­lel Down­loads in the Car­pool Lane.

Postponing Processing

In Per­form­ance on the Yahoo! Home­page, Nicholas Zakas de­fines time-to-in­ter­ac­ti­vi­ty as “the time be­tween the ini­tial page re­quest and when the user can com­plete an ac­tion.”  Be­cause the user’s per­cep­tion of per­form­ance is based on when he or she can get on with the next step, time-to-in­ter­ac­ti­vi­ty is a more im­por­tant mea­sure than time-to-page-load.

If we can post­pone pro­cess­ing un­til af­ter the user thinks the page is load­ed, that will give the per­cep­tion of bet­ter per­form­ance, even if it is in fact worse per­form­ance.  This is a form of asyn­chro­nous pro­cess­ing where­in we are com­plet­ing sys­tem pro­cess­ing in par­al­lel with hu­man pro­cess­ing.  As the user reads the web page and de­cides what to do next, the sys­tem is bu­si­ly com­plet­ing all the other things it needs to do.

In ge­ne­ral terms, web page com­po­nents fall in­to three ca­te­go­ries:  those that are need­ed to ren­der the page to the point where it is un­der­stand­able and use­able (e.g., the CSS that for­mats the page); those that will most like­ly be need­ed soon after in­ter­ac­ti­vi­ty has been achiev­ed (e.g., fre­quent­ly used Java­Script func­tions); and those that are less like­ly to be need­ed un­til later, if at all (e.g., func­tion­al­i­ty that is al­most ne­ver used).  Com­po­nents in the first ca­te­go­ry need to be down­load­ed and pro­cess­ed im­me­di­ate­ly, those in the se­cond ca­te­go­ry can be pro­cessed af­ter in­ter­ac­ti­vi­ty has been achieved, and those in the fi­nal ca­te­go­ry can be pro­cessed la­ter or on de­mand.  [We should be care­ful about on de­mand pro­cess­ing, though, be­cause it’s a guar­an­tee that the user has to wait.]

Preprocessing

Af­ter our code has fi­nished do­ing eve­ry­thing it needs to do for the cur­rent web page, and while the user is still read­ing the page and de­cid­ing what to do next, the sys­tem has no­th­ing to do.  Or does it?  If we can guess what the user will do next, why don’t we start load­ing and cach­ing the com­po­nents for the next web page?  We don’t even need to be 100% cer­tain about the user’s next move.  If we guess wrong, our web ap­pli­ca­tion isn’t do­ing any­thing any­how, so let’s go for it.

Of course, there are li­mits.  If we are only 10% cer­tain about the user’s next move, that may not be enough jus­ti­fi­ca­tion to place an ad­di­tion­al load on our ser­ver (or the cli­ent’s ma­chine, for that mat­ter).

Other Opportunities

This ar­ti­cle leans hea­vi­ly on the asyn­chron­ous down­load­ing of web page com­po­nents as an ex­am­ple, but there are other ways of achiev­ing asyn­chro­ni­za­tion.  Any event that oc­curs be­tween the time the user is­sues a re­quest and the time the re­quest is ful­filled is an op­por­tu­ni­ty.

Coming Up Next

My next ar­ti­cle will look at the asyn­chro­nous and de­ferred load­ing and ex­e­cu­tion of Java­Script, a to­pic that has ge­ne­rat­ed ma­ny on­line ar­ti­cles that seem to all say slight­ly dif­fe­rent things.  Com­ing soon to the mon.itor.us blog.

References

Best Practices for Speeding Up Your Web Site by Yahoo’s Exceptional Performance Team.  Published by Yahoo at developer.yahoo.com/performance/rules.html.  Accessed 2011.11.30.

High Performance Web Sites – 14 Rules for Faster-Loading Web Sites by Steve Souders.  Published by Steve Souders at SteveSouders.com/hpws/rules.php.  Accessed 2011.11.30.

Monitis Free Page Load Testing Tool.  Published by Monitis at pageload.monitis.com.  Accessed 2011.12.20.

Performance on the Yahoo! Homepage by Nicholas C. Zakas.  Published by SlideShare.net at www.slideshare.net/nzakas/performance-yahoohomepage.  Accessed 2011.11.30.

Performance Research, Part 4: Maximizing Parallel Downloads in the Carpool Lane by Tenni Theurer and Steve Souders.  Published 2007.04.11 by Yahoo at yuiblog.com/blog/2007/04/11/performance-research-part-4.  Accessed 2011.12.30.

Top Ten Web Performance Tuning Tips by Patrick Killelea.  Published 2002.06.27 by O’Reilly at OReilly.com/pub/a/javascript/2002/06/27/web_tuning.html.  Accessed 2011.11.30.

Web Performance Best Practices.  Published by google at <a href="http://code.google.com/speed/page-speed/docs/rules_intro.html”>code.google.com/speed/page-speed/docs/rules_intro.html.  Accessed 2011.11.30.

Website Performance: Taxonomy of Tips by Warren Gaebel.  Published 2011.12.29 by Monitis at blog.mon.itor.us/2011/12/website-performance-taxonomy-of-tips.  Accessed 2012.01.02

Try Monitis For Free.  A 15-day free trial.  Your opportunity to see how easy it is to use the Monitis cloud-based monitoring system.  Credit card not required.

The Monitis Exchange at GitHub.  This is the official repository for scripts, plugins, and SDKs that make it a breeze to use the Monitis system to its full potential.