540 likes | 814 Views
Extreme HTML. High Performance Web Applications Using Model 204 & Janus Web. Gary L. Bailey June 2nd, 2003. Agenda. Factors That Influence Throughput The ASP Paradigm Maximizing Throughput Check Your Cache (Settings) A different approach for Intranet Applications Summary/Conclusions.
E N D
Extreme HTML High Performance Web ApplicationsUsing Model 204 & Janus Web Gary L. BaileyJune 2nd, 2003
Agenda • Factors That Influence Throughput • The ASP Paradigm • Maximizing Throughput • Check Your Cache (Settings) • A different approach for Intranet Applications • Summary/Conclusions
Performance Constraints • Server Resources • Network Resources • Bandwidth • File Size • Frequency • Client Resources
The ABC’s of ASP • Client issues an HTTP Get or Post • Server retrieves data or performs a data base update • Server writes HTML and inserts data or results into the HTML data stream
What’s Wrong With ASP • Active Server Pages “merge” data and HTML “server side” and download HTML to the client (browser) • Maximizes Server CPU (Not Good!) • Maximizes Network Utilization (Worse!) • 90% Presentation • 10% Data • Most “active” Web Pages (includingModel 204 with Janus Web) use this model
But What About Cache ... • Well, since the data contained in the page could have changed … • We really don’t want the ASP page to cache • And we have to take special care that it doesn’t cache in the first place! • Use EXPIRES header response parameter, or • Use unique ISINDEX parameter, or • Use Cache-Control meta parameter
But What About Cache ... • By default, Janus Web does not write an expired or last-modified parameter when running a CMD ... • But caching is controlled by the client • Depending upon the client settings, the client could unexpectedly cache data • So be sure to set the Expires parameter to zero if you generate a page containing data • Janus Web DOES set the last-modified parameter for documents issued using the SEND command
But What About Cache ... • What we want is to cache resources that DON’T change, or change infrequently … • Pictures (GIFs, JPEGs) • Cascading Style Sheets • JavaScript • Raw (data free) HTML or XSLT documents • But not DATA • XML documents
Let’s Think About This ... • While Model 204 and Janus Web deliver high performance applications … • Minimizing server resource consumption will maximize end-user throughput • The HTML produced by the ASP model is difficult to reuse (ever parse HTML?) • Model 204 applications that merge data and HTML are constrained by QTBL and STBL
Let’s Think About This ... • Network resources are finite and expensive … • The ASP model maximizes bandwidth requirements • Both the data and its presentation must be downloaded for every iteration of the page • For a wide area network (WAN), the end-user experience is severely impacted by the speed of the network connection
Let’s Think About This ... • Client capacity is largely wasted • The system “idle” task consumes 99% of client CPU • Client capacity is easily “scaleable”, even for “thin client” networks
Achieving High Performance • Minimize Server CPU • Minimize Network Bandwidth Utilization • Maximize utilization of Client Resources
Maximizing Web Throughput • Segregate data from presentation • Deliver presentation (HTML or XSLT) separately from data • Cache presentation (HTML or XSLT) on the client • Deliver data using XML • Use Client Script or XSLT to apply data to HTML • Roadway uses JavaScript for intranet applications • XSLT is used for Extranet applications in combination with a proxy server that converts XSLT/XML to HTML
Client Requests HTML Document Server “Sends” HTML Document Client Requests CSS, JS, GIF Files Server “Sends” Static Resources Client Requests XML Document(s) Server Generates XML Document(s) I’m From Missouri ... Server ExecutesProgram Client Renders Page
Client Issues HTTP Request Server “Sends” HTML Document Client Requests CSS, JS, GIF Files Server “Sends” Static Resources Client Requests XML Document(s) Server Generates XML Document(s) Play it again, Sam ... Server ExecutesProgram Client Renders Page
Check Your Cache Settings • Controls how frequently the browser “checks” for a newer version of a resource • Controlled by the Last Modified Date/Time Parameter
Check Your Cache Settings • Every Visit To The Page • Consumes excessive Server CPU and network bandwidth • How often will a static resource change? • Automatically • Relies upon a frequency of change algorithm • Difficult to predict browser behavior
Check Your Cache Settings • Never • Never say never • Every Time You Start Internet Explorer • It’s a reasonable compromise • Guarantees the browser will check at least “once” per session • Problems can be solved by restarting IE • Provides a predictable behavior
Check This Setting Check Your Cache Settings • Make sure that cached resources are not deleted when the browser is closed • Defeats benefits of caching resources between browser sessions
OK, but … • A “resource” is defined by its URL including all of its ISINDEX Parameters www.mywebsite.com/myapp?field=value1 www.mywebsite.com/myapp?field=value2 • Isindex parameters are typically used to initialize the “state” of a web page • How can we initialize state without forcing the page to download? • And, since forms don’t cache by design, what about that case?
Problem solved! Next Question? Good Point … • Since each unique set of ISINDEX parameters forces a download, and • Since the default behavior of a form (HTTP POST) is to force a download • Don’t GET using ISINDEX parameters! • Don’t POST forms!
See, that was simple ... • Our HTML is “data free”, so downloading the HTML over and over again is a waste of network and server resources • The data displayed on a page is delivered using XML data islands • The trick is to pass “state” variables to a target page • Without using ISINDEX or POSTing a FORM
Initializing State ... • Client side cookies may be set and retrieved using JavaScript • Set a cookie before navigation in the source page • Retrieve the cookie in response to the “onload” event of the target page • Use state variables contained in the cookie to initialize the state of the target page, i.e. • Fetch data using XML data island(s) • Update the contents of the page
Initializing State … function fnSaveCookie() { vData = 'Field1=' + txtField1.value + '&'; vData += 'Field2=' + txtField2.value; vData = 'myData=' + escape(vData) + '; path=/'; document.cookie = vData; } URLencodes Field=ValuePairs Required to share cookies between pages
Initializing State … function fnLoadCookie() { oObject = new Object(); aCookies = document.cookie.split('; '); for (i=0; i < aCookies.length; i++) { var aCrumb = aCookies[i].split('='); if (aCrumb[0] == 'myData') { myData = unescape(aCrumb[1]); break; } }
Initializing State … aFields = myData.split('&'); for (i=0; i < aFields.length; i++) { aTokens = aFields[i].split('='); oObject[aTokens[0]] = aTokens[1]; } fnInitBody(oObject); } [] Syntax permits dynamic assignment of object property names
Initializing State … • Pass state variables using the clipboard function fnSetData() { myData = ‘Field1=’ + txtField1.value + ‘&’; myData += ‘Field2=’ + txtField2.value; window.clipboardData.setData(‘text’, myData); } function fnGetData() { myData = window.clipboardData.getData(‘text’); }
Initializing State … • Pass state variables to child windows using client-side objects … • Initialize an object in the parent window • Declare an initialization function in the child window • Call the initialization function from the parent window passing the object in the function call • Fetch data using XML data island(s) • Update the contents of the child page
Initializing State ... function fnOpenWindow() { oObject = new Object(); oObject.Field1 = txtField1.value; oObject.Field2 = txtField2.value; myChild = window.open(myChildPage.html); myChild.fnInitBody(oObject); }
Initializing State ... function fnInitBody(oObject) { var x1 = oObject.Field1; var x2 = oObject.Field2; … Do something useful … }
Page Structure … Header Tool Bar (Tabs) Side Bar Application Body Footer
Header Tool Bar Side Bar Footer App Body
Page Structure … • Overall Page Size Is Fixed • Sized to insure that the page can be displayed on a standard monitor • All Pages are the same size • Pages are not allowed to scroll • Size of each page component is fixed and absolutely positioned on the page • All pages are required to use uniform names for page components
Each Interaction results in navigation / new page Oops, I made a mistake … Backing up / starting over is hard to do … Sever Issues Form Client Posts Form Server Issues Response/New Form Client Posts Form Challenge/Response Web App … Web Page Web Page Web Page Web Page
3D Web Pages Web Application ApplicationComponent A Different Paradigm … • Components are hosted as HTML divisions or as inline frames within a controlling page • One component is visible to the end-user at one time • Components lose or gain “focus” (visibility) in response to events using DHTML
Inline Divisions • Inline HTML Divisions (DIV) are “part of” the parent page … • Changing “views” is nearly instantaneous • Can make the application “page” very large • Thus, difficult to code/maintain • Inline “views” are not easily reusable across multiple applications (drat!) • Can be simpler to code, no cross-frame issues to worry about
Inline Divisions • This block of HTML is Visible <div id=‘idDivA’ style=‘display:block’> … A bunch of HTML … Visible to the User </div> • This block of HTML is Not <div id=‘idDivB’ style=‘display:none’> … Some More HTML … Invisible to the User </div>
Inline Divisions • Update the ‘display’ style property in script to “show” or “hide” views if (idDivA.currentStyle.display == ‘block’) { idDivA.style.display = ‘none’; idDivB.style.display = ‘block’; } else { idDivA.style.display = ‘block’; idDivB.style.display = ‘none’; }
Inline Frames • The target of an inline frame (IFRAME) is a separate web page … • Contents do not need to download until used • Reduces the code size of the parent page • Thus, easier to maintain • “Views” can be reused within multiple applications (Nice!) • Or, reused as a dialog page (Better!) • But, we need to worry about cross-frame coding issues
Inline Frames • This frame is rendered by the browser <div id=‘idDivA’ style=‘display:block’> <iframe id=‘idFrame1’ src=‘’></iframe> </div> • This frame is present but not rendered <div id=‘idDivB’ style=‘display:none’> <iframe id=‘idFrame2’ src=‘’></iframe> </div>
Inline Frames • The ‘src’ attribute of the IFRAME element can be predefined in HTML, or set using script idFrame1.frameElement.src = ‘myPage1.html’ • The contents, events and methods of the child window are readily accessible from the parent container … idFrame1.txtField1.value = ‘something’; idFrame1.btnSubmit.click(); idFrame1.fnInitBody(oObj);
3D Web Pages Web Application ApplicationComponent HTTP XMLHTTPRequest XML Model 204/Janus Web Serving Up Data … • Data needs can be serviced using XML data islands, or … • XMLHTTP Request SOAP
XML Data Islands • XML Data Islands are native to HTML • Data is retrieved by setting the SRC attribute of the XML element using ISINDEX parameters • Causes the browser to issue an HTTP GET • Downloads are always asynchronous • But, there’s a limit on the length of the ISINDEX parameter • Which limits the amount of data/parameters that can be transmitted to the server • Excess is silently truncated by servers (including Janus)
XML Data Islands • Declare an XML element <xml id=‘idMyXML’ src=‘’></xml> • The source attribute can be preset in the HTML or set dynamically using script idMyXml.src = ‘myXMLDoc.xml?field=value’; • Set a call back function to parse the XML idMyXML.onreadystatechange = fnLoadXml;
XML Data Islands • Check the ready state of the XML document if (idMyXML.readyState != 4) return; • Then, get a pointer to the document element object; var oDoc = idMyXML.documentElement; • The contents of the XML document may be accessed using selectNodes and/or selectSingleNode methods using XPATH vNode = oDoc.selectSingleNode(‘/root/child’); vText = vNode.text;
XMLHTTP Object • XMLHTTP Object ships with MSXML • Supports GET, POST, PUT (or HEAD) HTTP methods • Downloads can be asynchronous OR synchronous • Using the POST method ensures that data will not be silently truncated • Request Headers can be set in script • Useful for meta data • Requires installation of MSXML on each client computer (ouch!) • But its worth the trouble!
XMLHTTP Object • Instantiate the XMLHTTP Object in Script oHTTP = new ActiveXObject("Msxml2.XMLHTTP"); • Set a callback function for asynchronous calls oHTTP.onreadystatechange = fnLoadData; • Construct request contents by concatenating field/value pairs (data/parameters) delimited by the ampersand … vBody = ‘Field1=’ + escape(txtField1.value); vBody += ‘&Field2=’ + escape(txtField2.value);
XMLHTTP Object • Open a connection to the server vMethod = ‘POST’; vUrl = ‘myXMLDoc.xml’; vAsync = true; vUser = null; vPswd = null; oHTTP.open(vMethod, vUrl, vAsync, vUser, vPswd); • Set request headers, send request body vType = 'application/x-www-form-urlencoded’; oHTTP.setRequestHeader('Content-Type',vType); oHTTP.send(vBody);
XMLHTTP Object • Test the readyState if (oHTTP.readyState != 4) return; • Get a pointer to the document element var oDoc = oHTTP.responseXML.documentElement; • Use selectNodes and/or selectSingleNode methods with XPATH to retrieve data elements oNode = oDoc.selectSingleNode(‘/root/child’) vText = oNode.text;
Web Application ApplicationComponent Web Dialog Pages • Web Dialog Pages may be used to “branch” & “return”, e.g. select from list … • Permits reuse of common functions, e.g. date picker … HelperApplication showModalDialog(Url, Obj, Opt)