The first thingwhich helped me a lot was PROCESSING
"CLOSE_CONNECTION=DEFER".. That hit me upto 10req/s (see in relation
with the other figure only ;)).
Hey neat. I'd heard conflicting reports, minimizing the impact of that
processing directive. Nice to hear that it was significant for your case.
I didn't optimize the postgres db so far.
Again, can't say without details.
* Optimizing the DB is a huge step, if it's of any significant size:
indexes, cluster, analyze and vacuum, etc. My company consults on such
things if you don't get a complete-enough answer from the list; and
PostGIS and PostgreSQL have mailing lists as well.
* If it's completely static data, you'll find that shapefiles
(especially shptree'd and/or sortshp'd ones) often perform faster than
PostGIS. This also frees you from the database cruft, if you're not the
DBA sort.
* Examine your classes and layers, and see what you can speed up there;
remember that classes are processed for every feature, in order, for the
first match, so putting the most-frequently-matched classes at the top
can save some CPU time, if you can still achieve the classifications you
want by doing so.
And I'm pretty sure there've been at least a half-dozen threads on the
mailing list's archives on the topic of optiizing mapserver's
performance. Try searching the archives or Googling, and see what comes
up, perhaps?
--
Gregor Mosheh / Greg Allensworth
System Administrator, HostGIS cartographic development & hosting services
http://www.HostGIS.com/
"Remember that no one cares if you can back up,
only if you can restore." - AMANDA
