it entirely depends on what your members do.
if lots of them visit default.asp then it is best to keep the number of forums low, if they rarely visit default.asp then the number of forums is pretty irrelevant. It is always best to keep the number of unarchived posts lowish as it helps with performance especially searching<

the only relevance with forums on the search is to the load time of the search form, it should not have much effect on the actual searching.<

Thanks guys!
I just didn't want to stack the deck up on a couple of forums only to have performance degrade in the long-run. I suppose I am simple, but I really do like the few approach most of the time.
Hey, Bruno at 60 MB does that mean that your archives are many? It looks like you have about 35,496 non-archived posts.
<

From my experience when the archives become very large, it is often difficult for the standard Snitz search to finish without timing out. This isn't a snitz flaw. I don't think.
This problem is a bit the result of when archiving is not performed regularly. So, when the archiving times out and then the same forum is archived again, the replies get duplicated in the archives because the originating topic does not get the point where it can be successfully deleted (again, this is because the replies did not finish archiving).
If it will help you, I wrote a little mod that helps with archiving in more segments than the standard Snitz allots for: http://forum.snitz.com/forum/topic.asp?whichpage=2&TOPIC_ID=67666#384563

You may want to contact your host to find out the longest time that they allow a script to run on your account. That may help you gauge what is going on.
I need to do something more to my little mod like check to see if the reply_id being archived is already an existing REPLY_ID in the FORUM_A_REPLY table. If it is, then skip it, and move on to the next reply_id and verify it until the process can start fresh with the correct reply_id in order to start the archiving process again. Also, for existing reply_ids that are duplicated, do a count of the archived reply_id, and if the count is more than 1, then delete the duplicates else skip it. That would actually be the first process I would run, and make the other a separate process. I am thinking that these things might help with cleaning up duplicates and not duplicating reply_ids in that table. Maybe it might take some of the fear factor out of archiving.
Honestly, I think duplicates happen more often than not because folks don't realize about the archive process timing out due to server limitations. Then the duplicates occur, and folks get frustrated and move on and away from it. In a perfect situation though, I assume that the standard Snitz archive process would work flawlessly.
<

Sure, I don't mind helping.
<