https://bugzilla.wikimedia.org/show_bug.cgi?id=29111
--- Comment #21 from MWJames <[email protected]> 2011-05-25 03:46:48 UTC --- (In reply to comment #19) > You're not going to see an improvement in server CPU performance in 1.17 > compared to 1.16 for a given page view request. This is not something we > optimised in 1.17. With proper tuning, the performance measured in this way > should be about the same. > > Note that 1.17 has more code and more source files than 1.16. If > eaccelerator.shm_size is too small to hold all the code, or if your server is > set up in a way that makes it very slow to check the source file modification > times, then this may produce a slow response time. Thanks for your insight, we never expected any improvements in relation to CPU performance but we also did not thought we need to rearrange software and hardware in order to compensate for the additional load that is now shifted towards the server, as I understand your comments correctly. >From our perspective and understanding, we thought we would do another migration and 1.17 would be just fine but I understand now that the features that have been build into 1.17 come at the expense of a higher CPU usage meaning that sooner or later we need to change hardware in order level performance. We only recognised while testing 1.170beta, we were always a bit behind 1.16.1 in terms of pages requests and load times and according to the numbers in our browser in how fast a page can be served, 1.16.1 shows always up first compared to 1.170beta. > ResourceLoader should provide an improvement in apparent performance, measured > at the browser with JS, CSS and images included, especially when there is a > large network delay between the server and the browser. But this may come at > the expense of an increase in server CPU usage, due to static file requests > being replaced by load.php requests. If this is a problem, it can be mitigated > by putting an HTTP cache in front of the MediaWiki installation. Increasing the eaccelerator.shm_size is certainly a tuning tweak but thinking about a HTTP cache is another league to balance performance. Having another piece of software that increases maintenance cost and labour work, is a hard selling point. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
