All,
I'm using Glassfish V3 (and thus Grizzly) as a replacement for Apache.
Grizzly has left me amazed with Java performance in general and some
internal tests show very high performance when serving static files.
(I've yet to compare it with Apache, but I think the comparison will
be favorable)
One thing I did notice was that while running a benchmark with more
than 300 concurrent connections will lock up Glassfish due to running
out of filedescriptors.
I'm not running anything other than Glassfish V3 / Grizzly at this
moment and it's serving just 32 unique files.
One source of potential problems may be here:
https://grizzly.dev.java.net/nonav/xref/com/sun/grizzly/tcp/StaticResourcesAdapter.html#207
A new FileChannel is created during the request (which means a file
descriptor is opened in handling the request, even if the file is
already opened elsewhere)
Maybe some form of cache could be used to retain these channel
references for a short while to prevent re-opening them?
This does not fully explain it, but it's a start.
Are there other locations that filedescriptors are opened?
A temporary workaround would be to increase FD count using ulimit,
which I've done.
BTW, another issue is that no matter what I do it would seem my poor
Gbit connection is a limiting factor.
Regards,
Barry
--
Barry van Someren
---------------------------------------
LinkedIn: http://www.linkedin.com/in/barryvansomeren
Skype: BvsomerenSprout
Blog: http://blog.bvansomeren.com
KvK: 27317624
irc: BarryNL @ FreeNode