I had a brief discussion with colleagues about thread-count setting in
glassfish.
I understand that this is the max number of worker threads that
grizzly can use, but what surprised me was that I believed that this
wasn't the max number of concurrent connections that grizzly can
process (concurrently send responses to). I know that the synchronous
nature of JavaEE doesn't allow grizzly to do much magic, but I
expected that grizzly could break the one thread per request paradigm
for static resources.
Unfortunately a simple tests with grizzly-v3-prelude and thread-count
5 shows that this is not true:
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
starts the download
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
starts the download
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
starts the download
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
starts the download
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
starts the download
wget --tries=1 --limit-rate=100
http://localhost:8080/foo.txt ->>
times out!!
Am I missing something? In my pet-project grizzly-sendfile[1] I was
able to create algorithms (still experimental) which can serve
hundreds of downloads with just a handful of worker threads. Why
doesn't grizzly do this for static resources? The same technique could
also be used for sending buffered JavaEE responses to slow clients,
which should increase throughput of the server significantly. Ideas?
/i
[1]
http://kenai.com/projects/grizzly-sendfile/pages/Home