Ran some tests with Grinder and repeated a few times. Saw no big difference, seems to be caused more by the VM warming up than by Wiki settings. Wiki on 4 core Linux, 500 pages, Client 4 Processes x 10 runs, each run reads all pages, so 20000 requests.
Greetings, Juergen Grinder script from here: https://github.com/kvalle/grinder-bloggpost/blob/master/post.md#example-2---testing-multiple-urls jspwiki.usePageCache = true 2017-09-01 18:07:30,189 INFO esprimo : elapsed time is 96989 ms 2017-09-01 18:11:42,579 INFO esprimo : elapsed time is 97293 ms 2017-09-01 18:24:39,773 INFO esprimo : elapsed time is 98262 ms 2017-09-01 18:26:45,058 INFO esprimo : elapsed time is 79536 ms 2017-09-01 18:28:34,470 INFO esprimo : elapsed time is 80146 ms jspwiki.usePageCache = false 2017-09-01 18:14:12,805 INFO esprimo : elapsed time is 105324 ms 2017-09-01 18:16:53,699 INFO esprimo : elapsed time is 88305 ms 2017-09-01 18:21:26,055 INFO esprimo : elapsed time is 87401 ms jspwiki.renderingManager.useCache = false 2017-09-01 18:31:58,457 INFO esprimo : elapsed time is 94469 ms 2017-09-01 18:33:56,753 INFO esprimo : elapsed time is 79983 ms 2017-08-30 17:05 GMT+02:00 Harry Metske <harry.met...@gmail.com>: > It would surely be interesting to see what the performance difference would > be. > > We could also ditch CachingProvider then probably? > And remove some code complexity... > > Grtz. > Harry > > Op 29 aug. 2017 12:07 a.m. schreef "Jürgen Weber" <juer...@jwi.de>: > >> Hi, >> >> ehcache-2.8.3.jar takes about a third of the JSPWiki.war size. >> >> Is it worth it? >> >> As for Filesystem page providers, the OS filesystem satisfies all caching >> needs. >> >> ehCaching is only useful for DB or the Subversion providers, but who uses >> them? >> >> As for caching rendered pages, this only works for non-dynamic pages >> (i.e. no CurrentTimePlugin). >> >> And I doubt, that even for static wiki pages, caching has an advantage >> on modern cpus. >> >> Greetings, >> Jürgen >>
