[dokuwiki] Re: Experiences in Scalability
- From: Harry Fuecks <hfuecks@xxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sat, 22 Oct 2005 00:30:43 +0200
An important thing here is data capture and avoiding this
http://www.procata.com/blog/archives/2005/02/24/flawed-microbenchmarks/
(i.e. I wouldn't recommend a benchmark plugin based on PHP functions
itself).
For me, the most interesting thing is how performance evolves over
time (as data volume grows), rather than a single performance
"snapshot". The change over time has a better chance of being
independent of local factors (e.g. specific hardware you're using)
while "snapshot" benchmarks are basically nothing you can make a
sensible comparison with and really tell you little.
Think the most valuable would be to have a something based on XDebug
or APD which captures profiles reports for a long time, archiving them
for later analysis. There's a good article here:
http://www.linuxjournal.com/article/7213 - particularily the tip at
the end about the IP address - perhaps a worthwhile plugin would be
something like a special admin "profiling cookie" which turns on
Xdebug / APD when the admin user is visiting.
In additional something that periodically captures stats about the
wiki would help (number pages, page sizes, index sizes etc.)
On 10/22/05, Andreas Gohr <andi@xxxxxxxxxxxxxx> wrote:
> On Fri, 21 Oct 2005 14:13:48 -0500 (CDT)
> "Joe Lapp" <joe.lapp@xxxxxxxxx> wrote:
>
> > Tim Bayer <tim.bayer@xxxxxxxxx> wrote:
> > > I was thinking about the limitations DokuWiki may have and I think
> > > the performance of DokuWiki is going to be based a lot off of the
> > > hardware running it. Any Thoughts?
> >
> > We don't have any hard numbers yet. Given some of the goings on in
> > the code, my personal opinion is that there's a lot of room for
> > improvement on the scalability front.
>
> I certainly agree with Joe on that point. Any improving patches are
> welcome :-)
>
> To answer your questions:
>
> The main scalability problem until recently was the search - it did
> search all files every time. The new search uses an index and is much
> faster. It's speed now depends on it's index size not on the number of
> pages. Would be nice if could gather some stats from the list users -
> everybody please post the following data (below is the data of
> wiki.splitbrain.org)
>
> find data/pages -type f|wc -l 658
> size of data/pages/ 4.9 MB
> size of data/cache/word.idx 206 KB
> size of data/cache/pages.idx 12 KB
> size of data/cache/index.idx 657 KB
> general search experience something around a second or two for the
> results (no hard facts here)
>
> Perhaps someone could build a benchmark plugin? Measuring the above
> infos and benchmarking a typical search, rendering the syntax page and
> so on...
>
> The next scalability problem is the speed and RAM used for rendering a
> page (means translating the raw wiki data to xhtml output). This
> basically depends on the size of the source page and the amount of
> markup used (more markup more instructions to parse).
>
> We've had some problems with large pages like wiki:parser hitting the
> default PHP 8MB memory limit. Simply increasing this limit to somewhat
> more solves the problem.
>
> Note that dokuwiki uses some caching mechanisms so the need for
> rendering isn't needed on every pageview.
>
> I guess there are other things to consider I just forgot. Unfortunately
> you didn't tell us what size of wiki you expect. if you're talking about
> several thousands of documents I guess you should consider an other
> engine like mediawiki or usemod.
>
> Andi
>
>
>
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
