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]]
  67
  68 >>>> IMHO, the best way to get a multithreaded ikiwiki is to rewrite it
  69 >>>> in haskell, using as much pure code as possible. Many avenues
  70 >>>> then would open up to taking advantage of haskell's ability to
  71 >>>> parallize pure code.
  72 >>>>
  73 >>>> With that said, we already have some nice invariants that could be
  74 >>>> used to parallelize page builds. In particular, we know that
  75 >>>> page A never needs state built up while building page B, for any
  76 >>>> pages A and B that don't have a dependency relationship -- and ikiwiki
  77 >>>> tracks such dependency relationships, although not currently in a form
  78 >>>> that makes it very easy (or fast..) to pick out such groups of
  79 >>>> unrelated pages.
  80 >>>>
  81 >>>> OTOH, there are problems.. building page A can result in changes to
  82 >>>> ikiwiki's state; building page B can result in other changes. All
  83 >>>> such changes would have to be made thread-safely. And would the
  84 >>>> resulting lock contention result in a program that ran any faster
  85 >>>> once parallelized?
  86 >>>>
  87 >>>> Which is why [[rewrite_ikiwiki_in_haskell]], while pretty insane, is
  88 >>>> something I keep thinking about. If only I had a spare year..
  89 >>>> --[[Joey]]