Eric,
Thanks for the information. Among other things, I now know that I'm
requesting what I need in the best way for our situation.

On Tue, 30 May 2006, LSTOWN-L automatic digest system wrote:

>Date:    Mon, 29 May 2006 16:17:18 +0200
>From:    Eric Thomas <[log in to unmask]>
>Subject: Re: Listserv Radio Button Front End
>
>> - tcpgui or any listserv query is just too slow to find all of
>>   a person's subscriptions (2.5 minutes)
>
>There are three main scenarios where it takes LISTSERV an abnormally long
>time to give you information about subscribers and the like:
>
>1. You are using the "wrong" command or the wrong logic in your script.
<snip>
>present case, you should be using QUERY * FOR [log in to unmask]

That is indeed the command used.

>2. You have a lot of DBMS lists, or a slow/remote DBMS, or some large DBMS

Nope- none.

>3. You have a lot of lists, or very large lists, and do not have the high
>performance (HPO) version of LISTSERV. It still shouldn't be taking 2.5
>minutes, though.

We have about 2000 lists. A few have a lot of subscribers (over 10k), with
a total of either 180k? 280k? registered names and an unknown number of
actual subscriptions. According to the points used, we ought to have HPO.
ANd our box is pretty small- 1Ghz Pentium with 1M memory. But cpu usage on
a long term basis is <20%, memory usage is not a problem. Most
distributions occur quickly, and the web interface responses are mostly
instantaneous or within a second or so- no complaints. I've had Lsoft
folks look at this, too. The only performance problems we see are commands
like this, and subscriber's corner for the listserv postmaster account.
And occasionally slow web page response if listserv is busy doing a large
distribution or one of my commands like q * for [log in to unmask]:-) It's
really hard to justify HPO to management, much as it would sometimes make
my life a bit easier.