I ran a grinder test now with spawning off 1000 thread to hit the
Geoserver application with WFS request and Geoserver reached the max
thread limit with the server replying with
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at HTTPClient.HTTPConnection.getSocket(HTTPConnection.java:3251)
at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2985)
at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2792)
at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2584)
at HTTPClient.HTTPConnection.Get(HTTPConnection.java:901)
at net.grinder.plugin.http.HTTPRequest$2.doRequest(HTTPRequest.java:366)
at net.grinder.plugin.http.HTTPRequest$AbstractRequest.getHTTPResponse(HTTPReque
Geoserver could not handle the amount of request I am systematically
finding it's limitation.
This may actually be much more of a test of the servlet container that
GeoServer is running in than GeoServer itself. I'd be interested to
see comparisons across servlet containers, and to see if the bottle
neck is in the container or in geoserver itself. And if in GeoServer
itself where it is so we can get it better. But thanks for this
testing, it's good to know this type of thing. If you do any more it
could be nice to post on one of the wikis, so others can look at the
information as well.
best regards,
Chris
Quoting Clint Lewis <louiecw@anonymised.com>:
Hi,
I ran a grinder test now with spawning off 1000 thread to hit the
Geoserver application with WFS request and Geoserver reached the max
thread limit with the server replying with
java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(Unknown Source)
at java.net.PlainSocketImpl.connectToAddress(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at HTTPClient.HTTPConnection.getSocket(HTTPConnection.java:3251)
at HTTPClient.HTTPConnection.sendRequest(HTTPConnection.java:2985)
at HTTPClient.HTTPConnection.handleRequest(HTTPConnection.java:2792)
at HTTPClient.HTTPConnection.setupRequest(HTTPConnection.java:2584)
at HTTPClient.HTTPConnection.Get(HTTPConnection.java:901)
at
net.grinder.plugin.http.HTTPRequest$2.doRequest(HTTPRequest.java:366)
at
Geoserver could not handle the amount of request I am systematically
finding it's limitation.
--
Kind Regards,
Clint Lewis
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642
_______________________________________________
Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geoserver-devel
This may actually be much more of a test of the servlet container that
GeoServer is running in than GeoServer itself. I'd be interested to
see comparisons across servlet containers, and to see if the bottle
neck is in the container or in geoserver itself. And if in GeoServer
itself where it is so we can get it better. But thanks for this
testing, it's good to know this type of thing. If you do any more it
could be nice to post on one of the wikis, so others can look at the
information as well.
Noted: Just downloaded and confirmed geoserver 1.3.0 vs Resin 3.0.17 - we will see if it does better.
I know Jetty uses the same servlet engine as Tomcat, is the difference in "weight" mostly due to
performance issues like the ones we encountered?
>This may actually be much more of a test of the servlet container
that
>GeoServer is running in than GeoServer itself. I'd be interested to
>see comparisons across servlet containers, and to see if the bottle
>neck is in the container or in geoserver itself. And if in
GeoServer
>itself where it is so we can get it better. But thanks for this
>testing, it's good to know this type of thing. If you do any more
it
>could be nice to post on one of the wikis, so others can look at the
>information as well.
>
>
Noted: Just downloaded and confirmed geoserver 1.3.0 vs Resin 3.0.17
-
we will see if it does better.
I know Jetty uses the same servlet engine as Tomcat, is the
difference
in "weight" mostly due to
performance issues like the ones we encountered?
I believe it may just be settings. I don't know if they changed the
defaults, but I remember that Jetty used to be a bit less performant
with the defaults because they gear them to development, instead of
production. I've never dug extensively into it though, it would be
great to have a wiki page on experiences. But that's part of the
reason we recommend using the war download for production instances,
and setting up one's own servlet container.