Re: zidestore 100%

by buzzdeee :: Rate this Message:

Hi,

at least I found a reason why the webui was so horribly slow the last days.
The zidestore was not really the problem. There seems to be a memory leak in
OGo1.0Beta2 webui, which I am using right now.
I updated two or three weeks ago, and it ran since then. Today I found the
memory usage of the webui was at around 45% of 2GB RAM. After restarting it,
it was back to at about 2-3 % of RAM.

users@... wrote:

> On 22. Nov 2005, at 16:59 Uhr, Sebastian Reitenbach wrote:
> >> ZideLook is a bit more efficient here, it fetches up to 64?
> >> contacts in
> >> one GET (so ~25 GETs insetad of 1500). But it uses a non-standard
> >> HTTP
> >> hack which is why it isn't in GroupDAV.
> > what is this for a hack, why is it not working with HTTP?
> > so the propfind is first going to retrieve the list of (new/
> > changed) contacts
> > and will then download them. What is the problem of requesting and
> > downloading
> > 64 or howmany ever, contacts in a row?
>
> Thats simple: HTTP doesn't have a method to request the content of
> multiple URLs in one step.
> One would need to introduce additional non-base-HTTP methods to
> support that (eg CalDAV does this with REPORTs), which is against the
> idea of GroupDAV.
>
> ZideLook just encodes multiple objects in a single URL, eg
> PROPFIND /Calendar/10203_10238_12837_1277_19271
>

thanks for the insights, does this is allowed/specified in the GroupDav
protocol? As I now now that it was the webui slowing down itself, and not the
zidestore, i can live with it as it is (well, a caching mechanism in the
kaddressbook would be really useful, but that's another story...).

kind regards
Sebastian

--
Sebastian Reitenbach Tel.: ++49-(0)3381-8904-305
RapidEye AG Fax: ++49-(0)3381-8904-101
Friedrich-Franz-Str. 19 e-mail:reitenbach@...
D-14770 Brandenburg web:http://www.rapideye.de

--
OpenGroupware.org Users
users@...
http://mail.opengroupware.org/mailman/listinfo/users

« Return to Thread: zidestore 100%