Thanks for the info,
There are obviously lots of areas concerning performance when developing an app
with Geoserver. Java Heap space, MaxPermSize, Tomcat settings etc.
The size of server Ram und number of Cores alone doesn´t create a fast server I
assume.
As I am not a java developer nor a linux guru and for me the whole area of
server performance is quite bewildering. Does anyone have a checklist which
could explain/pinpoint the areas which are needed to optimize a production
server / webapp? If such a thing does not exist, could someone maybe put the
following in order of importance so that I can do some tests?
I am using geoserver 2.02 RC4 / Tomcat6/ Linux Ubuntu Server 10.04 / Geoext /
Openlayers / Postgresql/ postgis
1. Java heap space
2. Java MaxPermSize
3. Tomcat6 settings
4. Javascript script size
5. PostgreSQL settings
6. Webserver settings
there are probably many others which I have not mentioned.
thanks,
Rob
________________________________
Von: Andrea Aime <andrea.a...@geo-solutions.it>
An: Steve Way <steve....@infotech-enterprises.com>
CC: Robert Buckley <robertdbuck...@yahoo.com>;
"geoserver-users@lists.sourceforge.net" <geoserver-users@lists.sourceforge.net>
Gesendet: Dienstag, den 28. Juni 2011, 12:06:51 Uhr
Betreff: Re: [Geoserver-users] Geoserver Architecture: How to assess
effectiveness
On Tue, Jun 28, 2011 at 11:23 AM, Steve Way
<steve....@infotech-enterprises.com> wrote:
> Hi Robert,
>
>
>
> I think 2GB server side is fine for Development, but to release to the
> public as a production is too low.
>
>
>
> The minimum I would have is 4GB – and this would probably only give you a
> descent amount of capacity for 5 concurrent requests.
Only? We have run GeoServer at the WMS benchmarks allowing up to 16 WMS
requests giving GS less than 2GB heap.
Past that we use control-flow to limit the amount of parallel requests so that
the others get queued.
But normally we find the limit is the number of CPUs, not much the memory
(I'd normally lock down WMS parallellism to numCpu * 2).
A 1024x1024 RGBA request uses a drawing surface of 4MB, multiply that
by the number of active feature type style in the style, and if you have
designed it properly you don't have much more than 4-8, that makes for
32MB tops per request, that is, 512MB of drawing surfaces for 16 screen
wide requests in parallel (or 256 tile sized requests in parallel).
Give it 1024MB and you should be good to handle an almost limitless
number of WFS requests in parallel (WFS request work full streaming,
the memory footprint of each is negligible).
Cheers
Andrea
--
-------------------------------------------------------
Ing. Andrea Aime
GeoSolutions S.A.S.
Tech lead
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 962313
http://www.geo-solutions.it
http://geo-solutions.blogspot.com/
http://www.youtube.com/user/GeoSolutionsIT
http://www.linkedin.com/in/andreaaime
http://twitter.com/geowolf
-------------------------------------------------------
------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users
