On Sunday 18 April 2004 10:53, Chris Holmes wrote:
> > When we were benchmarking GeoServer we ran into an interesting
> > observation - it
> > looked for all the world like requests were being serialized.
This
> > is not cool
> > - but at the time we blamed the web container and went on.
>
> Were you by any chance using mozilla to do this?
>
> Hey, I've been playing with some scalability stuff with geoserver
today,
> nothing scientific, just working with some large datasets, and I
think
> I may have hit on your issue with having geoserver do serial
requests.
>
> I was testing simultaneous requests today, checking to see if the
lite
> renderer's abort method works (I think it does, but I think we
still
> hold the image that it was drawing in memory, so I was getting some
out
> of memory errors - did make use of the free memory admin tool
though,
> which was nice (though it's got some issues with positive and
negative
> values, reports it freed negative abounts of memory)), and I
noticed if
> I issued three getMap requests in mozilla then the calls for the
second
> and then third would not be issued until the first completed. On
ie it
> would send them as soon as requested and start working on the
> responses.
AFAIK Mozilla uses HTTP 1.1 by default, so it uses persistent
connection,
and also as far as I rembember no more than 4 of those connection are
used simultaneously. Maybe IE doesn't use 1.1 or uses a higher number
of
connections? Also, separate IE windows are separate processes, whilst
separate Mozilla windows are the same process, so it may be they are
sharing
the same set of connection. Just wild guesses, I really don't know
what's
going on. Are you using Mozilla 1.6?
Yeah, 1.6. Yeah, I guessed it's something like IE windows being
seperate processes as well...
> I couldn't really test GetFeature since my mozilla gets all
> slow at anything over like 300 features, so it's just a pain to
work
> with for large getFeature requests.
So you're speaking about WFS requests? Funny, it's quite a bit
of time Mozilla I don't experience perf. problems with large
documents...
Well, it's only with these wfs responses that I do. Keep in mind that
essentially what I'm doing is sending like 5 or 10 megs of data that
Mozilla tries to display for me, doing its nice xml printing, all in
one really large window. It doesn't surprise me that it falls over.
IE will handle a bit more, but will still mess up with a big enough
request. But yeah, the problem is trying to actually portray a ton of
data. If I just saved the document it'd be much easier, I guess with a
save target as or something, or if we changed the mime type.
> Also, if anyone has any idea how to trash the graphic that the
> LiteRenderer is working on when stopRendering is called let me
know.
LiteRenderer cannot thrash it since it is provided from outside... I
think
it should disposed at the end of the request. I've attached a small
patch that
uses only one graphics object instead of two and that disposes it
when done.
It should be easy to apply with Eclipse (Team -> Apply Patch).
Sorry for not committing it myself, but I don't have time to setup
geoserver
to test it.
No worries about not committing at all, thanks a ton for the patch.
Just tested it and yeah, seems to work better, was not able to
reproduce my out of memory error, doing like 20 very large getMap
requests all at once, canceling 16 of them (just hit reload a few times
on 4 browser windows, one mozilla and three ie). Granted my cpu was
floored for quite awhile, but no out of memory errors. I also made one
small improvment on the patch you gave me, held the graphic as a
private variable and called dispose when abort was called if the
graphic was not null. Seems like it might help free up memory, and
doesn't seem to hurt anything. But yeah, it's looking like the lite
renderer is now performing quite nicely, as I tried pretty hard to get
an out of memory error, thanks a ton for all your help.
Chris
Best regards
Andrea Aime
Index: JAIMapResponse.java
RCS file:
/cvsroot/geoserver/geoserver/src/org/vfny/geoserver/responses/wms/map/JAIMapResponse.java,v
retrieving revision 1.20
diff -u -r1.20 JAIMapResponse.java
--- JAIMapResponse.java 18 Apr 2004 11:01:40 -0000 1.20
+++ JAIMapResponse.java 18 Apr 2004 14:38:14 -0000
@@ -263,7 +263,7 @@
BufferedImage.TYPE_INT_RGB);
//LOGGER.fine("setting up renderer");
- java.awt.Graphics g = image.getGraphics();
+ Graphics2D g = image.createGraphics();
g.setColor(request.getBgColor());
if (!request.isTransparent()) {
@@ -279,7 +279,9 @@
AffineTransform at =
renderer.worldToScreenTransform(dataArea,
paintArea);
- renderer.paint((Graphics2D) image.getGraphics(),
paintArea, at);
+ renderer.paint(g, paintArea, at);
+ g.dispose();
+
LOGGER.fine("called renderer");
map = null;
-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
----------------------------------------------------------
This mail sent through IMP: https://webmail.limegroup.com/
