dakar1Add my vote for this tag performance1Add my vote for this tag create new tag
, view all tags

Refactoring Proposal: Performance Improvements in Dakar


Reasons why this refactoring is needed, and why it is suitable for adding to the next release of TWiki.


One focus of the DakarRelease is to tune the performance of TWiki. This topic is a summary of work done in this area.

See ExaminingPerformance for discussion of the benchmarking strategy

See LatestCorePerformance for the latest benchmarks

Smaller Performance improvements

  • TWikiDotPm's handleSearchWeb: Replaced 26 calls to extractNameValuePair() with one extractParameters() call, with added benefit that new SEARCH parameters will be passed along automatically. -- PeterThoeny - 07 Oct 2004

Performance inprovements documented in other topics

Note: This list is a search on ""Performance" in the TopicSummary

-- PeterThoeny - 28 Sep 2004

Performance inprovements discussed in other topics (but not yet scheduled for Dakar)

Note: This list is a search on ""Performance" in the TopicSummary

Impact and Available Solutions


If necessary, developer documentation of new features and changed APIs introduced by this proposal.


Example uses of new features and changed APIs introduced by proposal.


Any comments on how the refactoring is implemented or could be improved


I just did some detailed studies using CPAN:Devel::SmallProf (a great tool) to analyse line-by-line performance. One thing that is abundantly clear is that TWiki performance is dominated by disc performance i.e. time spent reading topics. The reason the DEVELOP branch returns slower benchmark times is that the time spent in the sandbox reading the safe pipe for shelled-out comands is close on 30% of the total elapsed time.

It calls into question the validity of benchmarks where the runtime of a page view is insignificant compared to the time spent waiting on disk IO.

-- CrawfordCurrie - 12 Jan 2005

Would it make a difference if the topics where zipped? The topic size of TWiki/TWikiHistory (60KB) goes down to 20KB, so that means 0.3 times the disk reading time. I wouldn't know how much time unzipping would take though.

-- ArthurClemens - 12 Jan 2005

It is not a disk reading problem, but a perl implementation problem. I just made a grep of a string in our biggest web (1200 topics). First run takes 100 milliseconds, sucessives ones take 2 milliseconds of real time, including disk I/O. The inefficiencies are in perl code, they are not inherent to reading files.

-- ColasNahaboo - 13 Jan 2005

Having a slow machine in some ways is a good way to find performance problems - I'm not sure why the safe open code should be so much slower, as the underlying backticks implementation also uses pipes. Is it actually the $foo = <PIPE> type line that causes the problem?

-- RichardDonkin - 13 Jan 2005


-- CrawfordCurrie - 13 Jan 2005

Very odd, have never seen pipes as a performance issue on Unix/Linux - worth seeing if a cat of similarly sized file (via TWiki search for example) has same problem. Can you say more about your platform, e.g. Perl, Linux and Apache versions, and whether safe pipe open mode is on (presumably it is)?

Also, it would be worth bracketing the offending line with timestamps just to make sure.

This might be something to do with buffering - i.e. try setting local ($|) = 0 in parent before the fork - the local stops it being a global change which is best for ModPerl.

-- RichardDonkin - 14 Jan 2005

Broke your lock on the assumption that you'd finished.

I've never seen pipes as an issue either, which is why I suspect Colas is right.

My system is Suse 9.0

Linux 2.4.21-226-athlon #1 Tue Jun 15 10:26:33 UTC 2004 i686 athlon i386 GNU/Linux 
DMA is off on the TWiki disc, so disk access is well below par.

I previously bracketed the expression using Benchmark qw( :hireswallclock ) to confirm the CPAN:Devel::SmallProf results.

It's nothing to do with buffering. TWiki never set $| = 1 before DEVELOP, I only just added that. It has made no difference to performance. I'm not using any accelerators (mod_perl or speedycgi) when analysing. The idea is to optimise the "typical case" performance.

-- CrawfordCurrie - 14 Jan 2005

http://www.troubleshooters.com/codecorn/littperl/perlfile.htm#Piping in the Piping Efficiency part claims that Perl is slower than awk and C at handling pipes, but I've not heard this before. Don't see much alternative though we could try using temporary files - this could lead to disk full problems, particularly with 'show whole page in result' (BookView ?) type searches.

-- RichardDonkin - 14 Jan 2005

As recommended by the perlites, I changed as many strings as possible to single quoted, to avoid unneccesary interpolation during compilation. Makes a noticeable difference.

Also removed all the indirection functions that were used for accessing session objects; they were really just syntactic sugar, and involved an extra unnecessary function call. Again, makes a noticeable difference (though still not as much as I'd like).

Also remodelled View.pm so print output in three steps - before %TEXT%, %TEXT% and after %TEXT. That means the page layout is delivered to the browser before the text is ready, which gives a better "feel" to the load speed (see a big topic like TWikiVariables on ntwiki; the impact is quite noticeable.)


Oh, also fixed a problem with user lookups that was biting Anton.

-- CrawfordCurrie - 16 Mar 2005

That pages seems 10 times faster than on twiki.org! Surely there are other factors...

-- ArthurClemens - 16 Mar 2005

You need to compare apples with apples. ntwiki is running on a much less loaded server. The plan of record was to move twiki.org to that server, but that plan seems to have stalled.

-- CrawfordCurrie - 17 Mar 2005

Yes, Arthur, there are. It has to do with the ratio of real (user) entries to spurious entries in TWikiUsers. The 'fix' was to have the parser ignore the spurious. Now on TWiki.org there are lots of users so the spurious are insignificant, but on prototype sites there aren't many users.

Oh, that and the Dakar performance imnprovements, OO-ificiation of the code not withstanding, are really doing something. I've got cairo and dakar running copies of the same data (TWiki and Main webs excepted) on my internal server. Dakar does seem snappier.

Crawford, do you have any numbers to support this?

-- AntonAylward - 17 Mar 2005

I edited Anton's remarks above to try and put them in context.

On performance; actually, I have numbers that indicate the reverse, which is why I've been working on optimising DEVELOP. But it's very very hard to work out what's going on in order to optimise it, and it's doing my head in. frown

-- CrawfordCurrie - 17 Mar 2005

Hey got a suggestion. Has anyone tried profiling the app using dtrace?

-- BrianGupta - 22 Sep 2005

Nope. What's dtrace? Sounds interesting....

-- CrawfordCurrie - 22 Sep 2005

From the OpenSolaris site: "Trace is a comprehensive dynamic tracing framework for the Solaris™ Operating Environment. DTrace provides a powerful infrastructure to permit administrators, developers, and service personnel to concisely answer arbitrary questions about the behavior of the operating system and user programs"

See: http://www.opensolaris.org/os/community/dtrace/

-- RafaelAlvarez - 22 Sep 2005

This perl.com article covers how to use DTrace for Perl development.

-- RichardDonkin - 22 Sep 2005

Hmmmm - so it needs a Solaris box. OK, well, that rules me out then.

I have tried CPAN:Devel:DProf and CPAN:Devel::SmallProf. Neither gives useful results. I suspect the main problem is that TWiki is CPU intensive during compilation, which swamps out actual page rendering time.

-- CrawfordCurrie - 23 Sep 2005

Check out http://www.sun.com/bigadmin/content/dtrace/ It lists all the dtrace resources available... As for not having a Solaris box it's free, and it runs on x86/x86-64... I would offer to help, but time is something I don't have much to spare... One thought, you might be able to get Sun to help out as java.net is hosted on Twiki. (They are looking to get the dtrace word out)... If you are interested, I can reach out to my Sun rep, and see if they have any resources available.. (brian.guptaNOSPAMgmail.moc)

-- BrianGupta - 03 Oct 2005

I talked to a Sun guy who's really up on on dtrace, and he is interested in helping, but he's backed up for the next month or two. He is checking to see if anyone else has the bandwidth.

Oh.. one note.. When you say TWiki is CPU intensive during compilation, that is where dtrace can help. It can tell you what Twiki is doing, and where it is spending time during page compilation.. e.g what system calls... context switches, I/Os, etc.....

-- BrianGupta - 04 Oct 2005

Sun are TWiki users; twiki.org is hosted on one of their machines. You might point this out to them, and suggest how it is in their own interests to contribute to this work....

-- CrawfordCurrie - 04 Oct 2005

You might want to reach out to the Sun contact who provided you with the hosting. I am still waiting back to hear from my rep.

-- BrianGupta - 05 Oct 2005

My rep is swamped. He cannot help. You need to follow up with the Sun Rep that arranged the hosting... tell him you need help profiling an application with dtrace.

-- BrianGupta - 18 Oct 2005

Hey if anyone is interested in tackling dtrace. Here is a site that discusses profiling a Perl app with dtrace.. (And how to do it). http://blogs.sun.com/roller/page/alanbur?entry=dtrace_and_perl

-- BrianGupta - 21 Oct 2005

There are performance issues with the DakarRelease, see Bugs:Item711. We need to decide if we can release Dakar with the current performance (DakarRelease is significantly slower than CairoRelease). Follow-up in Bugs:Item711.

-- PeterThoeny - 22 Oct 2005


Edit | Attach | Watch | Print version | History: r39 < r38 < r37 < r36 < r35 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r39 - 2006-04-25 - CrawfordCurrie
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.