Doug, Thanks for this information. Your description of the "Definition Change Check Interval" is consistent with my understanding (and, well, its very name). And changes to it would certainly explain why opening a window (using either mechanism) after a structural change might or might not take a bit longer. What is most interesting is your description that with OpenWindow you "can do things" that you can't otherwise...so the mid-tier is somehow optimized for OpenWindow. That makes sense.
I happen to have a very generic piece of workflow that does pretty much all window openings for me. My solution to this whole thing was to install a global checkbox field used by this workflow to act as a switch: if it's selected windows get opened using URL's, otherwise OpenWindow. During my development (where I'm of course making lots of changes and have that Check Interval set to 0), I of course have this unchecked because I don't want to wait (in some cases up to 1/2 minute) to open an entry, but it'll probably be selected to use URLs in production. Thanks, Charlie On Wed, Apr 23, 2014 at 9:17 AM, Mueller, Doug <[email protected]> wrote: > ** > > Charlie, > > > > The Definition Change Check Interval is the key to the issue. > > > > What this setting does is identify how frequently the mid-tier checks the > AR System server for whether a > > definition has changed. When set to 0, it means that every access to the > system causes a check to the server > > to see if there has been change. When set to > 0, it means there are > checks at the interval set (number of > > seconds if I remember right) for changes to definitions. > > > > On dev systems, setting to 0 (or a small number) makes sense. You trade > off a bit of interactive speed for the > > currency of definitions because you are changing definitions and you are > trying out the changes soon after > > making them. > > > > On Production systems however, setting to a higher value – every hour or > even longer – is much more > > reasonable as definitions are NOT changing (or only at very specific > times) and you want the highest > > interactive performance. > > > > NOTE: I know that there may be some comments in even BMC docs that 86400 > is a good setting, but that is 24 > > hours and that seems like a REALLY long time to me. The check should be > fast and cheap if there are no changes and if there are changes, I really > don't want to wait for up to 24 hours to pick them up. I personally > > would go with a setting more like 3600 (one hour) so that changes are > picked up in a reasonable time (not > > necessarily instantly but within an hour). > > > > We can do things when we know what the window is (OpenWindow) but not when > we have no clue what you > > are going to open (the URL). So, you were getting good performance on > OpenWindow and a penalty on > > the URL. When you changed the "check every time" setting to something > that is periodic, you can see that the > > performance of the two is comparable. > > > > By the way, the check is actually in the background and doesn't really > affect interactive use – unless the > > background has loaded a new definition and then there may be a bit of a > longer load time for screens the first > > time after the change has downloaded. Except that is when time is set to > 0 so there is some interactive > > interaction. > > > > So, the issue you were seeing was because of a caching configuration > setting. The behavior of the windows > > and the interaction of the two different modes should be consistent with > each other. > > > > One other note…. The 8.1 sp1 mid-tier has done a lot of work around > eliminating the need to clear caches. > > We believe the issues with the browser cache on end user systems getting > out of sync has been completely > > solved (we have dynamic pages with unchanging URLs and the browser caching > model relies on URLs being > > the same so we have to force awareness of change internally to our pages > to get around the browser caching). > > And, the mid-tier correctly updating definitions (at the update interval) > has been tuned so that you should not > > need to perform a reload cache on the mid-tier anymore. The 8.1 sp1 mid > tier is compatible 7.6.04 and 8.0 and > > 8.1 servers (all patch levels). > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Charlie Lotridge > *Sent:* Thursday, April 17, 2014 12:07 PM > > *To:* [email protected] > *Subject:* Re: OpenWindow vs. PERFORM-ACTION-OPEN-URL > > > > ** > > A quick update... > > > > So, first, I noticed that in my earlier posts I kept saying Netscape when > I really meant Firefox. I'm getting old. > > > > Joe, I didn't mean to emphasize the time difference in browsers, but > rather the time difference between the OpenWindow vs. URL methods. But > Firefox (not Netscape!) is predictably faster. > > > > I do, though, think the conversation about back, forward, and (I'm adding) > refresh functions is very interesting and don't mind the segue. I don't > have direct experience but seem to recall ARSLIST conversations about user > complaints that Remedy apps are not very "webby", and have to believe that > the lack of support of these functions (through the normal mechanisms like > OpenWindow) contribute to this perception. Hence my effort here...instead > of trying to prevent the usage, trying to accommodate it. > > > > I think I've found a solution to the speed issue, though I still don't > quite know what's going on: I've had the "Definition Change Check Interval > (Seconds)" on my mid-tier set to 0 as is the recommendation for developer > mode. But if I set this back up to 86400, the PERFORM-ACTION-OPEN-URL > mechanism suddenly gets very fast. I haven't done any measurements, but it > seems comparable to the OpenWindow speed. > > > > I get that not many people are interested in this kind of stuff, but I'll > keep posting for posterity... > > > > On Wed, Apr 16, 2014 at 10:55 AM, Joe D'Souza <[email protected]> wrote: > > ** > > Unfortunately, its recommended to discourage the use of the forward and > back browser buttons. There is very little you can do from the application > side to enforce that. But discussing about that is another topic altogether > so I’ll resist. > > > > If your response varies with different types of browsers, then my gut feel > is that it is not anything that is happening at the application layer that > is causing those increased performance times or decreased performance > times. It is something that the browser itself is doing. Not being much of > an expert to deduce what that might be,, I’ll leave it to some other > browser experts to comment. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Charlie Lotridge > *Sent:* Monday, April 14, 2014 4:03 PM > > > *To:* [email protected] > *Subject:* Re: OpenWindow vs. PERFORM-ACTION-OPEN-URL > > > > ** > > Ah, got it. > > > > The bulk of the workflow is happening in an "On Display" action, and both > methods invoke it (the exact same workflow). Somewhat counter-intuitively > (given the situation), the faster OpenWindow action is also running an "On > Window Loaded" action (which doesn't do much) but is NOT being run by the > URL method. So just to make sure I'm clear, OpenWindow is running a > superset of the workflow that PERFORM-ACTION-OPEN-URL is causing to be run. > > > > While setup to run AL logging to check this (I'd like to mention here how > much I miss the easy setup for AL logging in the old WUT), I decided to use > the timing info in the log to capture some quantifiable stats. I didn't > exhaustively try all permutations (because it would've been exhausting), > but each of the following represents the average of 8 tests of each type: > > > > *Opening a comparatively simple form (148 mostly DO fields, 124 AL's, 38 > AL guides):* > > OpenWindow method using IE 11: 1.33 seconds > > URL method (to current window) using IE 11: 1.67 seconds > > > > OpenWindow method using Netscape: 1.10 seconds > > URL method (to current window) using Netscape: 1.55 seconds > > > > *Opening a comparatively complex form (732 mostly DO fields, 946 AL's, 241 > AL guides) [all using Netscape]:* > > OpenWindow method: 1.53 seconds > > URL method (to current window): 2.17 seconds > > Using browser's history "Forward": 0.05 seconds > > URL method (to new window): 2.03 seconds > > > > Clearly the form size is having an impact on all methods, which makes > sense. Netscape is uniformly faster than IE, which is also expected. > What's the most interesting here to me is just how fast the "forward" > mechanism...greased lightning. This is of course the same as the "back" > mechanism, it was just more convenient for me to test it using "forward". > > > > Unfortunately I still don't know just why the OpenWindow method is faster > than URL. I really like the functionality and usability of the URL method > over OpenWindow, and am debating if it's worth the extra cost (or, more > precisely, will the users think so). > > > > Anyway, thanks for the suggestions guys. > > > > -charlie > > > > > > On Sun, Apr 13, 2014 at 8:20 PM, Joe D'Souza <[email protected]> wrote: > > ** > > I had also thought of the authentication bit but I do not think it is that > as the authentication is stored as a cookie, so once authenticated, until > that cookie expires, another window that is opened should technically not > request authentication again. > > > > When I said search, I didn’t mean the search that happens on the request > ID. That is already indexed and is optimal. I meant searches that may > happen that may be designed on open window action or window loaded action, > that may be happening when you do a the url thingy and does not when you > use the open window action. I agree its unlikely to be that, but that’s > what I meant to ask you to check. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *LJ LongWing > *Sent:* Sunday, April 13, 2014 10:16 PM > *To:* [email protected] > *Subject:* Re: OpenWindow vs. PERFORM-ACTION-OPEN-URL > > > > ** > > Charlie, > > Is it possible the extra traffic is relating to authentication? I know > when you do a open window action, the window is opened 'in the same > session', but is it possible that when doing a URL call, it's having to > communicate with the web server to determine which session is yours, which > is taking a bit of time? > > > > On Sun, Apr 13, 2014 at 7:37 PM, Charlie Lotridge <[email protected]> > wrote: > > ** > > Thanks for the suggestion Joe. Unfortunately the solution is not going to > be that simple: I was actually using a request id in the search, so it's > not going to get more optimal than that. > > > > I actually did a side-by-side comparison earlier. I set up an AL that > would open an entry using OpenWindow, and another that opened the same > entry using a URL, both effectively doing the same exact search (using a > request id). The URL method took a full second more to load (about .6 for > OpenWindow vs. 1.6 seconds for the URL). Using the browser's network > monitor I can see that it's performing some additional network > transactions, though (again) I really don't how to interpret these results > yet. > > > > -charlie > > > > On Sun, Apr 13, 2014 at 1:57 PM, Joe D'Souza <[email protected]> wrote: > > ** > > I won’t pretend to know the answer – but have you ruled out some piece of > search workflow that might be running when you use the application command, > which might not be running with an optimal search criteria, which might not > be triggered during the regular Open Window action? I wouldn’t have thought > there would be a difference in the performance when essentially you are > doing the same thing. > > > > Joe > > > ------------------------------ > > *From:* Action Request System discussion list(ARSList) [mailto: > [email protected]] *On Behalf Of *Charlie Lotridge > *Sent:* Sunday, April 13, 2014 1:51 PM > *To:* [email protected] > *Subject:* OpenWindow vs. PERFORM-ACTION-OPEN-URL > > > > ** > > Hi, > > > > Recently I was experimenting using PERFORM-ACTION-OPEN-URL instead of an > OpenWindow action to open a Modify window on a specific entry (using the > ?eid=<request id> parameter). It's easy enough to use and I certainly got > it working, but the performance as compared to OpenWindow was abysmal. > > > > My guess is that this has something to do with browser caching...maybe > this method can't use the cache or something. But I'm not sure since I > don't really know anything about how browser caching works. I opened up > the Network Monitoring console on Netscape and do see some significant > differences in the request/response transactions, but I don't quite know > how to interpret it. > > > > Does anyone have any thoughts or experience as to why I'm seeing this > performance difference or how to mitigate it if at all possible? I've > tried it on each of IE, Chrome, & Netscape with similar results. > > > > FYI here are my reasons for potentially wanting to use > PERFORM-ACTION-OPEN-URL: when (in the natural course of navigating through > my application) the user wishes to modify some entry, I have some > generalized workflow that causes the app to open a Modify window. If the > window is opened using OpenWindow, though, and the user subsequently > attempts to refresh the browser page, it's converted to a Query (Search) > window and the context is lost. > > > > Similarly, I was hoping to preserve browser history functionality for the > user. If a user navigates from one entry to another (on the same for or a > different one), then the browser's Back and Forward functions should work > correctly and revisit the appropriate previously visited entries in modify > mode, but with OpenWindow they don't. > > > > Using PERFORM-ACTION-OPEN-URL accomplishes both of these goals NICELY and > I'd switch my generalized workflow to use it except for the performance > issue. > > > > Any thoughts? > > > > Thanks, > > Charlie > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
