tim@attdso.att.com (Tim J Ihde) (06/23/89)
I've gotten C-news up and running on our 3B2/600 running System V 3.1.1.
Before I go any farther, let me say that I'm quite impressed with the
overall package, and I appreciate the time and effort that you guys have
obviously put into it.
With a lead in like that, you can tell I've had a problem or two. First
of all, there was an initial problem with relaynews and permissions. The
program could not create the lockfile needed to post a new article. I
ended up removing the call to setids(), and now it seems to operate
properly with relaynews setuid to news.
Secondly, I've noticed that the L option in the sys file does not seem to
work properly. I've the following line in my sys:
LocalLog:!to.all,all,all.all/all,!ihave,!sendme:L:/bin/rmail news
The intent is to mail any locally created articles to news. The !to.all
at the beginning was necessary to exclude the ihave/sendme articles to
another machine. However, I find that I am also mailed any article created
on a machine one hop away from mine; so the L is acting like L1. I tried
explicitly stating L0; the result was the same.
The third, and most serious problem, has to do with performance on
ihave/sendme. Before I set up C news, I was using B 2.11 with the dbz.c
file simulating the dbm library. This was very quick with both normal
batches and with ihave/sendme's. With C news, I've found that the batches
are processed at least as fast as before. However, the ihave/sendme's are
now almost as bad as they were with B 2.11 _without_ the dbz.c -- read
unacceptably slow. It takes almost two hours to process an ihave with
400 message id's, on a fairly empty machine.
I've recompiled relaynews using dbz.c instead of Henry's dbm.c with similar
results.
My question here is: is this expected, or have I set a wrong option
somewhere in build? With a performance difference this great, I'm thinking
about dropping ihave/sendme entirely and just rejecting lots of articles
as duplicates. I'm getting a full feed from two machines, one as straight
batches and the other as a backup with ihave/sendme, both via 2400 baud uucp
(and both fairly local calls).
Any suggestions are appreciated.
tim
--
Tim J Ihde INTERNET: tim@attdso.att.com
(201) 898-6687 UUCP: att!attdso!tim
"First, you shall remove all the bugs. Then, you must cut down the mightiest
tree in the forest, with . . . a herring!" -- the Supervisor who says "Ni!"henry@utzoo.uucp (Henry Spencer) (06/24/89)
In article <1989Jun22.215559.20578@attdso.att.com> tim@attdso.att.com (Tim J Ihde) writes: >... an initial problem with relaynews and permissions. The >program could not create the lockfile needed to post a new article. I >ended up removing the call to setids(), and now it seems to operate >properly with relaynews setuid to news. The whole setuid business is a bit of a swamp; the just-released patch includes some small improvements. >Secondly, I've noticed that the L option in the sys file does not seem to >work properly... I *think* this is the same bug as one we heard about a few days ago, and fixed in the patch. >The third, and most serious problem, has to do with performance on >ihave/sendme... We plead guilty to not having paid much attention to ihave/sendme performance. We have a low opinion of ihave/sendme. >... It takes almost two hours to process an ihave with >400 message id's, on a fairly empty machine. I admit that's slow enough to seriously surprise me. I'll have to punt the issue to Geoff, however, since it's his code. >... With a performance difference this great, I'm thinking >about dropping ihave/sendme entirely and just rejecting lots of articles >as duplicates... Provided you don't incur major transmission charges, we think that's generally a superior approach. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu
henry@utzoo.uucp (Henry Spencer) (06/24/89)
In article <1989Jun22.215559.20578@attdso.att.com> tim@attdso.att.com (Tim J Ihde) writes: >... It takes almost two hours to process an ihave with >400 message id's, on a fairly empty machine. One clarification request: I assume that is *one* ihave message with 400 message ids, not 400 separate ihaves? Ihave/sendme simply cannot be made fast unless it is batched. That aside... Geoff says something is wrong if things are that slow; ihave processing is not exactly a marvel of speed, but it's not that bad. If you are using the fake dbm with a large history file, that could account for it -- the fake is dead slow when things get large. -- NASA is to spaceflight as the | Henry Spencer at U of Toronto Zoology US government is to freedom. | uunet!attcan!utzoo!henry henry@zoo.toronto.edu