Re: Mid Tier - Long Applet Load Time

[Don McClure]

** James:   The RPC-situation certainly adds to all these transport delays.  My main input was confirming experiences of some other users; specifically, the flush is necessary to guarantee that next form request does get the new form--and that the java vs _javascript_ change places additional load on the MT server (load previously borne by the web browser/plugins at the client--not overwhelming, but not inconsiderable).   In at least our experience in this University setting: the demands on server hardware certainly has not decreased the workload for the MT platform, in moving from MT 5.1.2 to 6.3 to 7.0--- and that is even for users on campus only a few hops removed from MT!       Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 >>> "McKenzie, James J C-E LCMC HQISEC/L3" <[EMAIL PROTECTED]> 17-Oct-06 10:05 AM >>> Don:   Jamie's problem is well known for long distance RPC traffic.  I attended a briefing on the Riverbed traffic shaping device and RPC is very 'chatty' and the longer the connection, the longer it takes to transfer information.  The ultimate solution is to not use RPC, but that is not available right now.  The second solution is to force the MT server to 'pre-cache' information AFTER the cache is flushed.  The way that BMC does updates is to wait until a form is requested and then send over form data from the ARS server to the MT server.  This is very slow the first time a form is called for.  Add a long and slow connection and this makes things much, much worse.  And I agree that the method used by MT 6.3 + needs work so that the system will update whenever a form is changed, not wait for a user to call for the form. James McKenzie L-3 GSI   ________________________________ From: Action Request System discussion list(ARSList) [mailto:arslist@ARSLIST.ORG] On Behalf Of Don McClure Sent: Tuesday, October 17, 2006 7:58 AM To: arslist@ARSLIST.ORG Subject: Re: Mid Tier - Long Applet Load Time ** Hi Jamie,   Rick Cook mentions complete new architecture; subject re-work includes a change in use of java. Specifically, MT 5.1.2 and earlier relied on client-side java, with some JRE version-specific issues. Example: MT 5.1.2 would not work with Java 1.5.01 mentioned in your architecture, at least in our environment.   Last information I had on MT 6.3: MT is server-side _javascript_ only, not relying on any java at the client at all, so the server dataflow and memory-management concerns are quite different.    Also, the 'freshness' indicator in MT is not that reliable, so MT cannot necessarily discern an ARS-side change without that cache-flush action (fo rcing a retrieve of current form constructions). HTH...   dwm   Don W. McClure, P.E. Systems Engineer University of North Texas [EMAIL PROTECTED] 940.565.3287 __20060125_______________________This posting was submitted with HTML in it___ __20060125_______________________This posting was submitted with HTML in it___