Re: Evaluation

> > My testing with zideone beta yielded 2 results which make proposing
> > using zideone impractical as it stands.
> > 1. Connecting to enterprises where I had more than 3K enterprises, the
> > server's zidestore process went to 99 percent processor usage just from
> > connecting to zideone, steady until outlook was stopped.  Even after
> > zideone had all of the enterprises in view.  That was with just one
> > outlook connection and I want about a hundred.
> 
> While that seems a bit high it isn't abnormal for the *VERY* first sync.
> [although I thought B3 had a pacing algorythm to avoid pummeling
> servers] The ZideStore server has to basically render the entire DB
> contents as vCard (VCF) for the GroupDAV clients (TB/ZideOne/Evolution,
> etc...)  BUT this only happens the very first time;  after that the
> content is served from the cache and throughput should be pretty good.
> If you look in /var/lib/opengroupware.org/documents you'll see all the
> VCF files once you've sync'd.  You can increase this efficiency even
> more by hashing the cache via the LSVCFCachePath/LSHashVCFCache defaults
> (should be in the ZideStore chapter of WMOGAG).

Searching in wmogag, the string LSVCF does not exist, at least in the
version I have.  There is SxCachePath on Pg58.
/var/lib/opengroupware.org/documents does seem to be the path, filled
with files.  LSHashVCFCache default does certainly change the look of
the directory, but the processor will still stay pegged at 99 until I
stop outlook,  I mean for hours and hours, non-stop cpu peggage.

Dirk

-- 
OpenGroupware.org Users
[email protected]
http://mail.opengroupware.org/mailman/listinfo/users