Been working on a scalability project that we started last year but never finished. It's for a R5 Domino web application that has been in use for almost 4 years. Currently, only a small group of people use the applicaiton (around 40) but we want to roll it out to over 500. The question is, can our little ole Domino app handle the load. To find out, we're using the Microsoft Application Center Test (ACT) product.
Over the next few weeks, I'll report back the results of our testing and what we have learned and confirmed during this time. To get you started, what do you think is faster, GetDocumentByKey or GetDocumentByUNID? And, do you think it matters on a database that is extremely busy with read/writes.
Other topics I'll cover:
- Some basics on how to use MS Application Center Test
- The affects of Reader fields and view performance
- View performance and index size with views that contain simple and complex column and view selection formulas
- WebQueryOpen and WebQuerySave agents, should you be concerned or not
- Alternatives to web agents
It's definitely been an eye opener for me. This project has given me the opportunity to confirm what I've been taught as things to avoid in Domino applications. It has also taught me a few things that I did not know or that I thought was minor in reguard to performance and scalability. The best thing, is that I have an ACT project that I'll be able to reuse to test our Domino App when we migrate the server to ND 6.5 later in the year. We'll be able to see what performance improvements ND 6.5 will give us.
If you find that GetDocumentByKey is faster than GetDocumentByUNID at any time, there's something EXTREMELY wrong. The UNID table is maintained at the ODS level -- it doesn't have to be updated by the indexer.
actually getdocumentbynoteid is fastest. Roughly speaking the NoteID is an offset into the NSF where it can find the note. A race would be interesting though.
I don't know if it's still the case, but Bob Balaban found a few years back that in real-world situations, byNoteID was actually slower than byUNID. One would not expect it to be so, and it's almost definitely an optimization error, but it was certainly true in the ND5x context.
Very interesting. I haven't tested byNoteID. But believe me... byUNID is MUCH faster than byKey. I saw a post on Notes.net of someone who wrote a LotusScript agent to loop thru docs using all three methods. However, their test was only reading the docs and not updating them. Therefore, their tests showed the byUNID was a little faster than byKey, but not enough to really jump out at you as a reason to modify your code.
When you have a lot of writes happening to docs, then byKey really starts to slow down as the indexor works hard to keep the view you use to lookup docs, indexed.
Did you try getDocumentByKey + document update with setting the view.AutoUpdate=false before processing ?
It should be a good boost...and will be interesting to compare with ByUNID
Could you elaborate what setting you use in ACT. We were toying around with JUnit/HTTPUnit (Domino only).
;-) stw
@stw - not sure what you mean by "what setting" you use in ACT.
I'm using VBScript in ACT to make http calls to Domino and then I analyze the data to see my response times. To get an idea of how scalable my app is, I simulate various # of users and then I gather CPU%/Memory/etc data from the server.
How did this project go? Any news to release