I would be very interested to find out what the slowness depends on. SOME level of slowdown has to be accepted going from the 14.x interface where one page does one and usually only one function, to 15.x where there are pages like the dashboard that collect multiple pages into one. These pages are not going to be able to load faster than the sum of the individual sub-pages. But the 27 seconds mentioned by another poster are clearly unacceptable, in fact I rarely accept anything beyond 1 second. I also want to point out that we had performance problems in the early days of 15.0 when the web interface suddenly did so much more but also required more from the lower levels, but most of these issues were addressed by 15.5, so I am very surprised at today's postings and want to make sure we take care of them before releasing 16.0.

I suggest setting DEBUG_TIME_ALL=1 (don't forget to export) and checking the log to see which of the web interface requests takes a lot of time. I don't use the web interface as often as the old-fashioned command line :-), but with the command line, about the only thing that is not sub-second on recent hardware (unless you do it on purpose, like a big DISTRIBUTE job with DomainKeys signatures) is a list index update if the archives are massive. I saw it taking up to 10 seconds on an admittedly previous-generation machine, and it drove me crazy. Most other operations take a fraction of a second and I can load up the dashboard in somewhere between 0.1 second and 0.25 second, empirically, and on the previous-generation hardware in question. I would start checking the logs if it took more than a second!

I now have a large Solaris x64 server and while SPARC could be different, with Solaris 10 the quotas seem to be reasonable and you shouldn't witness a process swapping itself to death while there are 20G of unused system memory. Admittedly I run LISTSERV on Windows but as I run Oracle on the Solaris box, I think I can honestly say that I have carefully surveyed every quota in the system and would have spotted anything that would be a problem for LISTSERV :-) And I made the big Solaris server my main unix development system as a global-recompile-from-scratch takes just 3 seconds with 16 CPUs and 10 15krpm drives, a big step up from my trusty Tru64 system whose support expired on 10/31 anyway. I think that by now I would have noticed a performance problem specific to Solaris 10, although you can never be sure.

  Eric