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

Performance issues with 4.0.1

After I upgraded to 4.0.1 from a 3.x version i noticed a significant impact in performance. Nothing complicated, just viewing pages and navigating around the site. We have a standard install, hardware has not changed (dual pentium ibm x330) and core software did not change (apache, perl, etc.). only twiki changed.

It was hard to categorize the degree of slowness until we ran an htdig index on twiki with 4.0.1. To make a long story short, we are experiencing latency at a factor 3x's slower than the last version. Details below:

before upgrade

[tmweb@dvt1.sys.adm2 /dvt/shared/search.twiki.tm.tmcs]$ head rundig.out.1
Start time: Thu Mar 2 13:02:51 PST 2006
Done Digging: Fri Mar 3 12:51:27 PST 2006

~1 day

after upgrade

[tmweb@dvt1.sys.adm2 /dvt/shared/search.twiki.tm.tmcs]$ cat rundig.out
Start time: Mon Mar 6 11:36:15 PST 2006
Done Digging: Thu Mar 9 11:57:36 PST 2006

~ days

Any chance this issue can be investigated? Is there a document that illustrates what changes impact performance? Perhaps we can investigate, but there's nowhere to start.

-- Contributors: RickOliver

Discussion

An awful lot depends on your setup. For example, what sort of login management are you using? Are you clearing sessions in code or using a cron job? What plugins do you have installed? What skin are you using? Have you made any local customisations?

In general on most servers we see TWiki-4 running at about the same speed as TWiki-3, with allowance made for the additional downloaded to the browser in the form of CSS and JS. Significant improvements are obtained running under mod_perl or PersistentPerl.

-- CrawfordCurrie - 10 Mar 2006

Well, except for the problems that occur due to using mod_perl. Or have they been fixed now?

-- MeredithLesly - 10 Mar 2006

You seem to have a selective memory Crawford.

I have never reported that version 4 (Dakar) was as fast as version 3 (Cairo). On the contrary.

The engine is about 10-20% slower and the many extra css and js files in the skin adds further to the time it takes to download the page. And that time is the BEST CASE.

That is with localization disabled and {Sessions}{ExpireAfter} set to a negative number and sessions clean by cron.

Rick. If you did not need multiple language support before - disable it completely in configure. Additionally set {Sessions}{ExpireAfter} to for example -21600 and let cron run tools/tick_twiki.pl once per day during the night.

Also make sure that tooltip is disabled for the links (that also cost performance in Cairo).

You should expect to be able to optimize the speed so TWiki4 is about 30% slower than Cairo if the number of plugins is 15 or less. With really many plugins Dakar is actually gaining in a little.

Cairo ran very badly in mod_perl. But if you only use the standard plugins mod_perl works fine with TWiki 4 if you follow the exact method shown in ModPerlUnix.

Last - TWiki4 has more features and probably requires more RAM. If you have very little RAM and disks start swapping you are dead. So make sure you have a gig of RAM or so.

I have not yet measured what becomes TWiki4.0.2 but it seems on the skin side that going away from tables and back to DIVs makes the browsing experience feel faster. The browser starts showing the contents faster and the perception of speed is a lot depending on that. But the engine will not be faster in 4.0.2 since it is a bug fix release. Some mod_perl improvements have been made that should make 4.0.2 more mod_perl friendly also and mod_perl makes 4.0.X faster than Cairo without mod_perl.

3 times time increase is not something I have ever seen. Worst case I have seen is 60-70% slower and that was before turning off localization and especially {Sessions}{ExpireAfter} which cost a lot on performance and is not at all necessary. Wiping sessions with cron is very fine and TWiki4 has a very nice script for it.

-- KennethLavrsen - 10 Mar 2006

Thank you Kenneth for sharing your comprehensive experience.

-- PeterThoeny - 10 Mar 2006

hey crawford! we are running an almost standard 4.0.1 with BugzillaQueryPlugin, BugzillaListPlugin, CalendarPlugin and a couple of plugins we wrote for a project server we have running internally. I believe we are using the cgi session plugin with htaccess authentication that comes standard with the package install. Other than a couple additional markup additions (--strikethrough--, @@bold red@@) we haven't made any other changes. The skin is the default one that came with 4.0.1.

I'm not aware of how we are clearing sessions, but the latency was noticed immediately. We had a critical bug in our last version that was causing topics to become erased so we upgraded in a hurry.

Thanks for the tips Kenneth I will install those over the weekend and report back to the group. I believe our twiki box has a gig of ram, so we are good there. Would it help if I attached video of new vs. old twiki loading topics?

The particular effect of htdig's search indexes taking 3x's as long leads me to think maybe a 'view-lite' plugin of some sort is in order. A really fast view of a page without all the baggage or features a standard page might include.

-- RickOliver - 17 Mar 2006

So Kenneth, I couldn't wait and made a bunch of changes this morning based on your feedback. Specifically the "Session" and "Language" settings.. things have improved considerably.. still slower than the last version but more on par with your 30% estimate. Thanks very much.

-- RickOliver - 17 Mar 2006

Edit | Attach | Watch | Print version | History: r7 < r6 < r5 < r4 < r3 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r7 - 2006-03-17 - RickOliver
 
  • 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.