[Kroupware] OpenGroupware.org formed through SKYRiX open sourcing its Groupware server

[Helge Hess]

On Donnerstag, 10. Juli 2003, at 17:03 Uhr, Andrew Kohlsmith wrote:
> I am currently evaluating Exchange4Linux (exchange4linux.org) -- It 
> uses one
> big badass database for everything as well.  I've been dumping tons of 
> data
> into it to try and test it in terms of speed and compatibility with
> Outlook.

AFAIK the problem with E4L is, that they store *every* MAPI attribute 
as a single SQL row which obviously doesn't scale.

> E4L stores _everything_ in a postgres database, including email.

Which is a very bad idea. SQL database are for storing multiuser items, 
not for email - the transaction and integrity overhead for an almost 
exclusively user centric store like email is certainly too high.

Cyrus or Courier are very good choice for email.

> Speed so far has been crappy, but I am working on tuning pgsql for 
> better
> speed, which I think is a large part of the problem, although moving 
> the db
> to a fast SCSI storage system and throwing a ton of processor 
> (P4/2.2G) at
> it has causes the new bottleneck to appear to be the Python server 
> itself.

The problem is that the E4L connector does not "understand" the MAPI 
messages. It just splits them up into separate rows and stores them as 
raw attributes. Since a MAPI message has about 50-100 individual 
attributes you end up with 50-100 times the rows actually required (in 
other words, with a MAPI plugin which properly handles MAPI messages 
you can serve about 50 times more users on the same hardware 
[oversimplified]).
This is not a problem of a SQL database per se, but of the modelling of 
the E4L database schema and MAPI adaptor.

best regards,
   Helge
-- 
OpenGroupware.org	- http://www.opengroupware.org/