james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Bagnara <apa...@bago.org>
Subject Re: [IMAP] MessageRow and MessageFlags
Date Wed, 14 Mar 2007 00:15:57 GMT
robert burrell donkin ha scritto:
> On 3/13/07, Stefano Bagnara <apache@bago.org> wrote:
>> robert burrell donkin ha scritto:
>> > On 3/13/07, Noel J. Bergman <noel@devtech.com> 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.


To unsubscribe, e-mail: server-dev-unsubscribe@james.apache.org
For additional commands, e-mail: server-dev-help@james.apache.org

View raw message