]> sipb.mit.edu Git - ikiwiki.git/blob - doc/todo/multi-thread_ikiwiki.mdwn
0beea6fe23356e007d2de5d9a4beecb3335fec35
[ikiwiki.git] / doc / todo / multi-thread_ikiwiki.mdwn
1 [[!tag wishlist]]
2
3 [My ikiwiki instance](http://www.ipol.im/) is quite heavy. 674M of data in the source repo, 1.1G in its .git folder.
4 Lots of \[[!img ]] (~2200), lots of \[[!teximg ]] (~2700). A complete rebuild takes 10 minutes.
5
6 We could use a big machine, with plenty of CPUs. Could some multi-threading support be added to ikiwiki, by forking out all the external heavy  plugins (imagemagick, tex, ...) and/or by processing pages in parallel?
7
8 Disclaimer: I know nothing of the Perl approach to parallel processing.
9
10 > I agree that it would be lovely to be able to use multiple processors to speed up rebuilds on big sites (I have a big site myself), but, taking a quick look at what Perl threads entails, and taking into acount what I've seen of the code of IkiWiki, it would take a massive rewrite to make IkiWiki thread-safe - the API would have to be completely rewritten - and then more work again to introduce threading itself.  So my unofficial humble opinion is that it's unlikely to be done.
11 > Which is a pity, and I hope I'm mistaken about it.
12 > --[[KathrynAndersen]]
13
14 > > I have much less experience with the internals of Ikiwiki, much
15 > > less Multi-threading perl, but I agree that to make Ikiwiki thread
16 > > safe and to make the modifications to really take advantage of the
17 > > threads is probably beyond the realm of reasonable
18 > > expectations. Having said that, I wonder if there aren't ways to
19 > > make Ikiwiki perform better for these big cases where the only
20 > > option is to wait for it to grind through everything. Something
21 > > along the lines of doing all of the aggregation and dependency
22 > > heavy stuff early on, and then doing all of the page rendering
23 > > stuff at the end quasi-asynchronously? Or am I way off in the deep
24 > > end.
25 > >
26 > > From a practical perspective, it seems like these massive rebuild
27 > > situations represent a really small subset of ikiwiki builds. Most
28 > > sites are pretty small, and most sites need full rebuilds very
29 > > very infrequently. In that scope, 10 minute rebuilds aren't that
30 > > bad seeming. In terms of performance challenges, it's the one page
31 > > with 3-5 dependency that takes 10 seconds (say) to rebuild that's
32 > > a larger challenge for Ikiwiki as a whole. At the same time, I'd
33 > > be willing to bet that performance benefits for these really big
34 > > repositories for using fast disks (i.e. SSDs) could probably just
35 > > about meet the benefit of most of the threading/async work.
36 > >
37 > > --[[tychoish]]
38
39 >>> It's at this point that doing profiling for a particular site would come
40 >>> in, because it would depend on the site content and how exactly IkiWiki is
41 >>> being used as to what the performance bottlenecks would be.  For the
42 >>> original poster, it would be image processing.  For me, it tends to be
43 >>> PageSpecs, because I have a lot of maps and reports.
44
45 >>> But I sincerely don't think that Disk I/O is the main bottleneck, not when
46 >>> the original poster mentions CPU usage, and also in my experience, I see
47 >>> IkiWiki chewing up 100% CPU usage one CPU, while the others remain idle.  I
48 >>> haven't noticed slowdowns due to waiting for disk I/O, whether that be a
49 >>> system with HD or SSD storage.
50
51 >>> I agree that large sites are probably not the most common use-case, but it
52 >>> can be a chicken-and-egg situation with large sites and complete rebuilds,
53 >>> since it can often be the case with a large site that rebuilding based on
54 >>> dependencies takes *longer* than rebuilding the site from scratch, simply
55 >>> because there are so many pages that are interdependent.  It's not always
56 >>> the number of pages itself, but how the site is being used.  If IkiWiki is
57 >>> used with the absolute minimum number of page-dependencies - that is, no
58 >>> maps, no sitemaps, no trails, no tags, no backlinks, no albums - then one
59 >>> can have a very large number of pages without having performance problems.
60 >>> But when you have a change in PageA affecting PageB which affects PageC,
61 >>> PageD, PageE and PageF, then performance can drop off horribly.  And it's a
62 >>> trade-off, because having features that interlink pages automatically is
63 >>> really nifty ad useful - but they have a price.
64
65 >>> I'm not really sure what the best solution is.  Me, I profile my IkiWiki builds and try to tweak performance for them... but there's only so much I can do.
66 >>> --[[KathrynAndersen]]