One of our servers supports a single, large database. The database is 3.5 GB with just over 1 million documents. The database is maintained by a web application with no load. The server is a Dell Power Edge 2500 with a dual P3 1.4 GHz processors and 2GB of RAM.
Since the upgrade, we have seen the HTTP response increase 3 and 4 fold in a couple of instances. In one case a Lotus Script agent is accessing a view containing around 100 documents all of the same form type. In the second case a Java agent is accessing two views containing several hundred documents, and each view contains documents of a single form type.
Using Windows performance monitor and task manager we have seen that a single user invoking one of these agents will cause nhttp.exe to grab all available CPU and hold on to it for upwards of 8 to 10 seconds before processing completes.
We believe that the size of the database is a factor. We copied a 11 MB database with the same design and containing 2600 documents to the server containing the large database. For this smaller database, the HTTP response time for both agents was 1 to 2 seconds.
We have researched this forum for postings related to HTTP performance and found several references to the HTTPQueueMethod notes.ini parameter. When we added HTTPQueueMethod=2 to the notes.ini file, the HTTP response time did not improve.
Disabling web transaction logging to files in the server configuration did not have any appreciable effect on the HTTP response.
We have read through the referenced performance tuning FAQ’s and focused on the design of the views in question (i.e., selection formula and column formulas) and found no obvious problems with any of the formulas in the views accessed by the agents.
Does anyone have any explanation for slower HTTP response where the overall database size is large, but views being processed are quite small?
Run web agents concurrently is Enabled. In my original post I attempted to indicate that load is not an issue, though. The server/database/web application is not heavily used and during our analysis we have shown that we can create the problem with just one user invoking one of the agents in question.
Your question about the views being used by the agents is a fair one, and we have analyzed the views for efficiency. In my original post I indicated that the number of documents in the views being processed by the agents are very small. Also, the agents have been reviewed and no obvious inefficiencies have been noted.
We have looked at all of our server settings, and we are reading up on DDM in Domino 7 to see what type of data probe creation and data analysis we can do on the agents’ processing.
The question I am asking the readers of this forum is a very simple and straight forward one, though, and I will repeat it from the earlier post.
Does anyone have any explanation for slower HTTP response where the overall database size is large, but views being processed are quite small?
The answer to your question is yes, performance in general can vary quite a bit if the db size is large, even if a view is small. I think your Q is more about the agent accessing these small views, not a user accessing these small views, right? If the agent is using db.search, for example, you’d expect a significant performance change if the db size is large vs small.
However, you would not expect this to change much from ND6 to ND7 if all other parameters remain consistent, and certainly one would hope it would only get faster after upgrading, not slower.
I can give you suggestions for how you might troubleshoot a performance problem in general, but not sure if you’re looking for that.