Dear Alexey,
>> 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.
I don't believe Barry was complaining about a possible fd leak, but
rather about how heavy GF leans on the number of fd's available. This
means that for high-volume sites with lots of static content, GF needs
more fd's than another app server might need. Personally I believe
this is a documentation issue, rather than a bug of any kind. The
documentation of GF might advise raising the fd's, or at least explain
the relevant errors messages.
That said, perhaps GF could eek out more performance by reusing
resources that are open anyway. I doubt a lock-free hashmap of sorts
to cache the open files in would hurt much. The overhead would be in
the order of a check and possible an add/remove operation on that
cache-map.
Without measurements of the effect on the performance when reusing
such resources we cannot tell either way, though. Barry thinks it
might help, you dismiss it. I prefer to wait until someone sat down
and actually measured it.
So.... Anybody with a little spare time? :-)
--
Kees Jan
http://java-monitor.com/
kjkoster_at_kjkoster.org
06-51838192
The secret of success lies in the stability of the goal. -- Benjamin
Disraeli