james-server-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Draeger ...@joachim-draeger.de>
Subject Re: IMAP Draft: Cluster
Date Thu, 06 Jul 2006 13:00:45 GMT
Hi Ahmed,

Am Donnerstag, den 06.07.2006, 10:47 +0200 schrieb Ahmed Mohombe:
> > In a worst case, when nobody is ill or on holidays, you have at least
> > one open connection per user all the time. 
> How would one handle in the JVM and code these very long lasting connections?

Why? Are there issues? 
I'm not aware of any problems with many sockets treated by many threads
running a long time apart from the not avoidable network, cpu and memory
consumption. 
We should try to keep the data hold by the sessions small. If there are
really many users it should be possible to run an optimistic setup: not
all connected users will start the most expensive operations at the same
time. So maybe it is needed to have a strategy for the worst case:
Before everything gets so slow that nobody can do anything activate a
dynamic connection limit.
In this case the IMAP server should run on a separate machine not to
influence smtp/spooling on high loads.

Is that the direction of your question?

Actually there is a inactivity limit of 30 minutes defined in the RFC
and clients should be able to deal with the fact that they might be
thrown out from time to time.

> Also, doesn't this require too a totally different testing approach?

IMO for low level tests not at all. For session based tests we  have to
continue making the optimistic assumption that if it works one time it
should work all of the time.
Of course long time fine tuned stress tests will be very important. I'm
very curious to see how the first alpha release performs with the
to-be-written imap-postage module!
Until that i can really only make dim presumptions about how many
concurrent users are possible. 10? 100? 1000?

> >> Clustering at DB level would mean to not support dbfile, file and other 
> >>   types of repositories.
> > 
> > Clustering at DB level would just mean following some rules in the
> > implementation. DBMS are designed to be accessed simultaneously from
> > multiple hosts.
> > dbfile mmh, good point. I just made a few thoughts. There are also
> > various solutions to access a network file-system without a single point
> > of failure. 
> What about JCR? (e.g. the Jackrabbit implementation). Could
> it solve some of the problems, or it is too far away from making
> it usable as a "file system" for IMAP?

Well, I don't have any knowledge about JCR. I tried to quickly browse
some docs/faqs. 
But it seems to be able to use it reliable Jackrabbit uses a JDBC
back-end, too. And I guess it wasn't made to store lots of emails. The
overhead of implementing this might be greater than using JDBC directly.
This gives us the ability to tune performance.
How do you think JCR might help?

> What are the minimal performance requirements for  JAMES's first IMAP implementation?

As i said above I can only make assumptions. But it is an important
question. The first goal is to have something stable.
I think the cpu/memory usage for pure protocol handling is not that
higher than in POP3. The critical part is moving the data.
Apart from directly accessing mime-parts or performing searches it
should compare to a smtp/pop3 session.
Did anyone try how many simultaneous POP3 sessions are realistic to have
an acceptable throughput? 

> Doesn't the IMAP protocol impose at least some "hints" regarding performance and timings?

Not really. Maybe clients have timeouts. Apart from that there are no
timing issues. The client has to deal with the fact that an answer for a
command may take long. The time when IMAP was designed internet was
probably a very very slow business. :-) 
So the benchmark will be what the user will accept. 

> Thanks in advance,

I really appreciate any input.  

Joachim


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


Mime
View raw message