Hiya
On Fri, Jul 24, 2009 at 10:51 AM, Oleksiy
Stashok<Oleksiy.Stashok_at_sun.com> wrote:
> Hi Barry,
>
>> 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)
>
> Right, we open the file for each request, which means we allocate
> filedescriptor, but then we don't forget to close the file, so descriptor
> should be released.
The FD's are released after the request.
>
>> Maybe some form of cache could be used to retain these channel
>> references for a short while to prevent re-opening them?
>
> For some usecases, probably, cache could optimize performance. But under
> heavy load, when clients request different resources - it could become a
> bottleneck. Also I'm not sure, if it's possible to perform read/write
> operations on one FileDescriptor from different threads simultaneously.
>
> So, probably cacheing may optimize performance for some cases, but, IMHO,
> the implementation we're having now is not causing any file descriptor leak.
True, there is no leak at all.
I'd be interested in doing further tests with larger numbers of files
being hit (since I can generate them and the test config from a small
Java app I made)
>
>> This does not fully explain it, but it's a start.
>> Are there other locations that filedescriptors are opened?
>
> Yes :)
> Actually each network Socket, NIO Selector allocates a file descriptor.
Ah, learn something new every day. Thanks!
>
>> A temporary workaround would be to increase FD count using ulimit,
>> which I've done.
>
> After you increased ulimit and leave the test running for example for hour
> or more, do you see the issue? If not - it probably means there is no leak,
> if yes - we can continue investigation.
> Which app are you using for stress testing?
I've run a test for several hours under this kind of load and not
noticed any crashes.
Basically the only thing of note is Glassfish using more FD's than for
example Jetty.
Increasing the file count is not an issue for me, I was merely curious.
I'm using siege for stress testing and I generate static content with
random data using a simple Java app that also creates the urls.txt
Siege is being run from a separate server on a local switch.
Might be interesting to see how much I can get when running it
locally, but it would also skew the results a little.
>
>> BTW, another issue is that no matter what I do it would seem my poor
>> Gbit connection is a limiting factor.
>
> :))
>
> Thank you.
>
> WBR,
> Alexey.
>
>>
>> Regards,
>>
>> Barry
>>
>> --
>> Barry van Someren
>> ---------------------------------------
>> LinkedIn: http://www.linkedin.com/in/barryvansomeren
>> Skype: BvsomerenSprout
>> Blog: http://blog.bvansomeren.com
>> KvK: 27317624
>> irc: BarryNL @ FreeNode
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
>> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_grizzly.dev.java.net
> For additional commands, e-mail: users-help_at_grizzly.dev.java.net
>
>
--
Barry van Someren
---------------------------------------
LinkedIn: http://www.linkedin.com/in/barryvansomeren
Skype: BvsomerenSprout
Blog: http://blog.bvansomeren.com
KvK: 27317624
irc: BarryNL @ FreeNode