[Date Prev][Date Next]
Re: 8 hours tests ends with inconsistent DB.
paul k wrote:
While totally agreeing with your deployment strategies I would not count
them as proper arguments for the matter at hand (benchmarking OL). I may
be ignorant but I'd expect a poorly configured system to perform poorly
and of course not doing things as you expect but not to misbehave or
fail. If the underlying DB is not configured explicitely, fall back to
sane defaults, if you hit the resource limits of hardware or whatever
mechanism, the application should behave gracefully.
While there are many well-known techniques for gracefully dealing with
resource shortages, the OpenLDAP code base (and the UMich code it
derives from) were not originally written with these techniques in mind.
It takes a substantial rewrite effort to get there. The OpenLDAP code in
2.2 is already much more resilient than the old UMich code, thanks to
some substantial rewriting that has already been done.
To restate - given where the code started, fixing this is easier said
than done, but it *is* being done. If you'd like it to happen faster,
you know that help is always welcome. In the meantime, there's no
substitute for a properly administered system.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
Symas: Premier OpenSource Development and Support