Hi there,I created a web-based app for 500 users to handle applications for leave. There’s a view for the secretaries where they can see all documents for a whole year (until now, there are approx. 3000 documents for 2005).
This view (displayed in $$ViewTemplateDefault-form) is called via
“db.nsf/(WebApproved2005)?Openview&start=1&count=150”.
Due to the amount of docs, I wrote a WebQueryOpen-agent which generates a navigation-bar to scroll thru all docs (“< prev | 1 | 2 | 3 | next >”).
My problem is that is takes almost 20 seconds to display the first 150 docs. First I thought that the “scroll-agent” takes that long, but it only takes < one second.
The displayed view exists of three columns:
-
name of employee, sorted ascending, hidden
-
date of absence, sorted ascending, hidden
-
HTML-code to display in browser
Any ideas what causes to loong delay?
One more thing: it seems to be irrelevant, what number the “count=”-parm contains - I tried it with 3000 and it took only three seconds longer…
Any help will be greatly appreciated!
Buzzy
Subject: Tuning web-apps
Does the view contain documents that make extensive use of readers fields?
If so, that is likely to be the problem as the view needs to check all of the documents to determine how many are visible to the current user.
Performance can probably be improved by using a single category view categorised by the reader or similar.
HTH - Rufus.
Subject: RE: Tuning web-apps
HiAs Rufufs Said.,It may will be the one oy the main reason.or else., even the date/time functions also influence the opening of the view.Check the below link (Section:View Properties).This may help u.
http://www-10.lotus.com/ldd/today.nsf/Lookup/AppPerfpt1
Subject: RE: Tuning web-apps
Hi,well I’m using @Text(@Year(from))=“2005” | @Text(@Year(cancelfrom))=“2005” in view-selection an @date(from) in the hidden column…that’s it…maybe I can try to insert a categorized column w/ the year…
Thanks,
Buzzy
Subject: RE: Tuning web-apps
Gee, didn’t know that reader-fields have that side-effect. Well, every doc has 11 reader-fields :-/Would it help, if I put all values into one single reader-field?
Because due to the data’s sensibility, I have to use reader-fields…
I just tried another (categorized) view (own docs - about 40) which is called w/ “restricttocategory”…takes even longer to open 
Thanks,
Buzzy
Subject: RE: Tuning web-apps
RestrictToCategory should be much faster, provided that the user’s category contains only the documents he/she should be able to see. Consolidating your Readers fields will not help to the extent that you hope, I’m afraid.
Subject: RE: Tuning web-apps
Well, but removing the reader-fields means that someone theoretically could open a document by its ID, right? And if THAT happens, we’re really screwed :-|OK, maybe I’ll talk to our data protection officer (gee, that sounds much better than the german “datenschutzbeauftragter” g)…
Thanks,
Buzzy
Subject: RE: Tuning web-apps
No – I meant using the combination of RestrictToCategory and Readers fields should be much faster than Readers fields alone – provided that only documents the user should be able to see are in the user’s category. (If there are a lot of docs in the category that the user can’t see, you lose the advantage of the category.)
Subject: RE: Tuning web-apps
Well, I’ll give it a try…this won’t help the secretaries though, because they can see all docs, but who cares }:-}
Thanks,
Buzzy