This is in Release 4.0., unfortunately.
Originally reported by GŁnther Fischer in twiki-dev.
fixed in svn:8675 ?
For those that wish to get this fix
The SVN 8675 fix is the same as posted on TWiki:Codev.PerformanceIssueOfTWiki04x00x00
On my installation (no mod_perl) a longer text topic loaded in 1.6 seconds before this fix and 1.2 seconds after. So patch is recommended.
Lavr, I do know you want to promote the user experience when timing your installation; I believe the timings you post here are done on a default setup, and includes loading of images / css.
Please state very explicitly, when you post numbers that are not TWiki:Codev.AthensMarks
-style benchmarks (core / close to core).
OK. Here is the method for the timing.
- Measurements are done from another computer then the one running the TWiki server so that the browser does not take CPU time.
- Measurements are done using a text topic that can be seen on the screen without scrolling.
- Measurements are done with the same topic in Cairo and Dakar.
- The page has been loaded several times so that images and style sheets are cached since this is how 99% of all pages are viewed.
- Browser is setup to "Check for newer versions of the pages" -> "Every time you visit the page" as this is the way users have to have their browser setup to use CMS sites and Wikis. Otherwise they keep on missing the update they just did.
- When browser is checking versions it does not download the entire images and style sheets. It starts by doing a http GET of the page. followed by a sequence of GETs for each element with "if modified since" in the http protocol. The Apache server returns a "304 Not Modified" instead of retransmitting the entire page.
- The measurements are done by capturing the Ethernet traffic on the client machine using Etherreal.
- The definition of page loaded is when the browser Acknowledge the last received info as this is the same moment that it displays the resulting page.
- Internet Explorer is always used because I have noticed that the browser does not send the final ack until it actually shows the page.
In this particular bug report it was the code execution (time from first GET to first HTML segment returned) that got extended.
Hope this put some light on my numbers. I will copy this description to TWiki:Codev.DakarPerformanceIssues
as it should have general interest beyond this bug report.