I’m adding a web front end to a Notes database. The changes I’ve made include adding the ToolsRunMacro command to WebQueryOpen to run a LotusScript agent . The agent contains simple logic that’s similar to what appears in the QueryOpen event. (It primarily assigns hard-coded values to global variables.)However, when opening the form on the web, it takes at least 5 minutes for the WebQueryOpen and the agent to execute, even with a high speed connection.
I’d appreciate any ideas on why the performance is so slow on the web, especially since the logic is similar to that in the QueryOpen which executes quickly when the database is accessed through Notes.
Thanks.
Subject: Form Takes Several Minutes to Open on the Web
WQO agents are known and documented performance bottlenecks. If you don’t NEED 'em, don’t use 'em. Oh, and globals? No such animal. There are no persistent LotusScript values on the web. If you need to make values available for more than one code type/event, they’ll need to be stored as field values. If the agent actually replicates your Notes client QO event, it either:
a) assigns values to Variants that dissapear when your agent terminates; or
b) will not compile
depending on whether or not you’ve used Option Declare/Option Explicit.
Subject: RE: Form Takes Several Minutes to Open on the Web
Might it be more efficient to store values in a profile document (using @SetProfileField) rather than in fields on the main form?
Thanks again.
Subject: RE: Form Takes Several Minutes to Open on the Web
Yes, it would be. By factors of, well, quite a lot really.
Subject: Form Takes Several Minutes to Open on the Web
WQO agents do cause a hit on the server performance-wise, but 5 minutes is a code issue, not a WQO issue.
Also, if you’re considering setting profile fields and then reading them later using @GetProfileField on the web: don’t. Profile fields are cached heavily by the web server. They’re great for frequently-read, infrequently-written variables, but horrible for passing ever-changing parameters around. Simply reloading a web page with @GetProfileField on it can show different values each time if the profile field has changed within the past several minutes.
Why don’t you post the code you’re trying to run?
Subject: RE: Form Takes Several Minutes to Open on the Web
The giveaway here was “hard-coded”. If the data (as opposed to just the means to acquire the data) can be put into a script, then profile documents/fields will work splendidly. And the “global variables” part is a direct pointer to at least one code issue – a misunderstanding of the role of LotusScript in web applications.
Subject: I think you misunderstood my point…
Working with profile fields through script is fine, as is using @SetProfileField. It’s @GetProfileField that is the concern.
If @SetProfileField is used to set profile fields through the web server then subsequent @GetProfileField calls over the web will possibly return old data for several minutes. If you’re not using @GetProfileField, then great - no problem. But if you do, you’re looking at serious (and documented) caching issues. I don’t want Shane to implement a web solution revolving around profile docs/fields and after that attempt to use @GetProfileField to show up-to-date data, because he won’t always get it.
On the flip side, @GetProfileField formulas evaluated over the web are incredibly fast. They’re a fantastic solution to pseudo-cache frequently-used data (configuration settings, etc.) over the web.
Subject: No, I didn’t…
… the aim seems to have been to use stable values, otherwise “hard-coded” would have been a truly silly phrase to use, don’t you think? It’s exactly the situation in which @GetProfileField is supposed to be used.
Subject: Re: No, I didn’t…
It’s exactly the situation in which @GetProfileField is supposed to be used.
It is, within the context of just this one form. But there are potential design scenarios I can envision where relying on this technique across multiple forms and attempting to reuse profile documents will cause problems of the exact nature I’ve described. It can definitely be done as you describe, but Shane needs to be aware of the potential problems that can occur if the technique is also applied to other areas within the same application.
Subject: Form Takes Several Minutes to Open
While the code primarily assigns hard-coded values, there will be scenarios whereby varying values will also be assigned. The intent is to pass values (both static and varying) between documents created from different forms. Sorry I didn’t make that clearer. I gather from Erik’s responses that it’s not advisable to use @GetProfileField under scenarios where the values can vary because of timing issues on the web. In such a case, it would seem as if the values to be passed should be stored in fields (as Stan first suggested) without relying on profile documents.
Thanks.