Subject: | |
From: | |
Reply To: | |
Date: | Thu, 2 Jun 1994 23:06:07 +0200 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
On Thu, 2 Jun 1994 16:01:00 EDT "John F. Chandler" <[log in to unmask]>
said:
>1) Is there an unpredictable component in the CPU time due to system
> load, such that there is no "fix" for this problem?
In theory, yes. New messages are indexed before the search starts. But in
practice, you can't have more than a couple dozen at most. Unless of
course the list owner routinely updates the archive files, which resets
the index. But that would create problems for INDEX subscribers anyway.
>2) Is there a less CPU-intensive method of requesting messages, such
> as the "/ship" command?
Hardly... These are just variants on submitting a database job.
>3) Does the fact that I habitually strip out the blank lines between
> entries add to the CPU burden in any way?
The code that converts your request into a concrete series of database
instructions is very fast, and it isn't timed anyway (the database code
starts its own timer when it begins).
>4) Does the fact that failure reports always break off after the
> separator line for the first requested message mean that the
> failure always occur while LISTSERV is extracting that first
> message?
It suggests that the index was reset, and that this left no time to
retrieve the first message (indexing cannot be interrupted).
In principle the only way you can burn a lot of cycles is if the index
was reset (and the list is large), or then if you request a very large
amount of items. The search is more like a selection - you supply the
item numbers directly, so the database is not really searched. The code
that formats the output is in REXX, but if you're retrieving a dozen
messages or so, it should complete in a few seconds. The only thing that
can really eat up a lot of cycles is an index build from scratch.
But, in principle, the index shouldn't get reset unless the list owner
does a DATABASE REFRESH or updates one of the archive files.
Eric
|
|
|