On Tue, 1 Aug 2000, Chris wrote:
> Let me tie this into an earlier bug. As you'll recall, I had
> problems with the dig hanging on some domains - making the dig a
> real nightmare for me. I would spend a lot of time having to dig
> until I hang, delete the offending domain, start over, on & on &
> on until it'd run. That has definately been fixed. Now, during
> the dig, I can actually see these offending domains, because
> there is a longer than usual pause before the timeout hits &
> things move on. If that specific code can have a quicker
> timeout, the time I might be losing earlier, would be more than
> gained back by quicker timeouts in that specific code-fix.
In the 3.2 code, try:
<http://dev.htdig.org/htdig-3.2/attrs.html#tcp_wait_time>
<http://dev.htdig.org/htdig-3.2/attrs.html#tcp_retries>
and of course the original timeout (which sits at a higher level).
> Here are my files:
>
> -rw-rw-r-- 1 root root 24002560 Jul 30 08:43 db.docdb
> -rw-rw-r-- 1 root root 5238784 Jul 30 08:43 db.docs.index
> -rw-rw-r-- 1 root root 147042304 Jul 30 08:48 db.excerpts
> -rw-rw-r-- 1 root root 298757120 Jul 30 08:46 db.words.db
> -rw-rw-r-- 1 nobody nobody 2723840 Jul 30 08:48 db.words.db_weakcmpr
> -rw-r--r-- 1 root root 2215936 Jul 30 08:48 root2word.db
> -rw-r--r-- 1 root root 2920448 Jul 30 08:48 word2root.db
>
> I have no explanation or ideas as to why it may take numerous
> searches before sufficient data gets cached to speed things up.
> I have 512Meg Ram, dual 600's under the hood.
I don't have an easy explanation either. I'm certainly filing this in a
mailbox to check again as we near another release. It's something that, at
least, should be mentioned in the release notes if others see it too.
Certainly the effect will be greater if we start using higher-level
caching of results.
Thanks!
-Geoff
------------------------------------
To unsubscribe from the htdig3-dev mailing list, send a message to
[EMAIL PROTECTED]
You will receive a message to confirm this.
