robert burrell donkin ha scritto:
On 3/13/07, Stefano Bagnara <[EMAIL PROTECTED]> wrote:
robert burrell donkin ha scritto:
> On 3/13/07, Noel J. Bergman <[EMAIL PROTECTED]> wrote:
>> Robert Burrell Donkin wrote:
<snip>
>> This is orthogonal for having the blob be in a
>> separate table. The latter allows us improved DB performance (and
>> sharing
>> of the blob, if that were ever useful).
>
> AFACT message_body contains the body as a blob (but performance is
still
> poor)
>
> - robert
How did you measure this performance?
it's not properly benchmarked, just general usage with timings
In my tests the dbonly solution
has always been the faster in a typical scenario (I know every case is
different, but messages greater than 20k are less than 1% on my systems).
ever used nio for file -> socket?
Sorry for not being clear: I was referring to our current
implementations of the MailRepository/SpoolRepository service exactly as
they are implemented now.
I've no opinion on the theoretical issue, except thay any file base
database simply introduce a new layer, so possibily only limit the
performance of the underlying layer. For databases using their own
filesystems then the theory is more complex.
The AIO stuff in mina could help writing file based scalable solutions.
The worst case scenario is lots of clients sending receiving BIG files
really slowly. For db this is a PITA because this need a connection for
every client. For files, in practice, this is not so much better as it
could seem, but easier, for sure, to an average level.
Btw this is too abstract: I just wanted to make it clear that I don't
have any problem with file based repositories. If Jackrabbit was better
at this we could even use it directly. Unfortunately its streaming
support is lacking, and I don't know any library/framework out there
that supports high concurrency / big-and-slow data streaming against
db/dbfile/file backends, so we probably have to do our own way. I will
welcome any improvement on the current code, or any new implementation
of the repositories! I'm not tied to any line of the current code.
Stefano
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
