Hi,The main problem that I see in nsf files is that when the size bypass 5 GB, performance becomes poor and opening a view takes lots of time and the nupdate task takes lots of time to update index and consumes lots of resources on the Domino Server.
I haven’t use before the “Shared, desktop private-on-first-use views”, but I have run a small test and noticed that the size of these views is 0 on the server.
Can this type of views be used to solve the problem that I am facing? I know about desktop views disadv in design change and space on users PC, but sometimes storing couple of views on each user PC instead of having it on the server and being indexed each 15 minutes is not bad.
Subject: “Shared, desktop private-on-first-use” views save db size
Sam,
There are some articles about performance on the Developer Network that might give some insight into such matters IBM - United States
But the basic rules I would use here are as follows:
There is no magic 5gb cliff. However, since your server is trying to run agents, do replication, update views, help users, etc., at some point each of these is taking long enough to bump into the other tasks, which exacerbates the whole thing, and that’s probably when you’re noticing the problem.
View indexing can be time consuming for the server. Each view typically refreshes super fast, but if you have hundreds in a db and the db has gbs of data that changes rapidly, then that can make it slower. Likewise, you may have many such db’s on your server.
Storing view indexes locally on a user’s desktop is cheap for the server, but I’ve usually found that overall it’s not a good solution. You end up with out of date (design) local views hogging hundreds of mbs or more on many users’ desktops, and that’s no fun.
Subject: RE: “Shared, desktop private-on-first-use” views save db size
First of all, allow me agree with Raphael. There is no magic size jump.
One of major problems that we came to was sorting inside view problem, that creates really huge views and kills performance.
Shared - desktop personal on first use views have their uses… On bigger views every single time user accesses the database - BANG - all data of the view needs to be refreshed. ALL of it. It’s Dynamically Builded Views…
And try to think how to change them. Almost impossible.
Another problem is an Readers access in views - but it’s more problem on access to the view.
So, my advice is :
Divide Databases.
If you have archivable info - divide it in databases per year or such. Build index database that allows connection to related area.