2011/1/6 Alex <mrzmanwiki(a)gmail.com> Thanks. I would appeciate an algoritm to evaluate those parameters together, weighting them to have a significant, sigle "heavyness index." of the page. Then, removing or adding code would easily allow to mark the critical code. Alex ("the other one") :-)

On 07/01/11 07:50, Aryeh Gregor wrote: I think the maximum was set to 100 initially, and raised to 500 due to user complaints. I'd be completely happy if users fixed all the templates that caused pages to use more than 100, then we could put the limit back down. -- Tim

2011/1/11 Tim Starling <tstarling(a)wikimedia.org> Thanks Tim. So, implementing a simple js to show that value (and the other three data too) in small characters and into a border of the page into the page display is not completely fuzzy. As I told I hate to waste resources - any kind of them. It's a pity that those data are not saved into the xml dump. But I don't want to overload the servers just to get data about servers overloading. :-) Just another question about resources. I can get the same result with an AJAX call or with a #lst (labeled section transclusion) call. Which one is lighter for servers in your opinion? Or - are they they more or less similar? Alex

2011/1/11 Aryeh Gregor <Simetrical+wikilist@gmail.com<Simetrical%2Bwikilist@gmail.com > Overall, I'd advise you to do whatever minimizes user-visible latency. > That directly improves things for your users, and is a decent proxy > for server resource use. So use whichever method takes less time to > fully render. This is rather more practical than trying to consult > MediaWiki developers about every detail of your program's > implementation, which is unlikely to be used widely enough to greatly > affect server load anyway, and even if it were we couldn't necessarily > give intelligent answers without knowing exactly what the program is > doing and why. I'm already using your suggestion, today I replaced a complex test template from our village pump (replacing it with a link to a subpage, visited by interested users only) and, really, the difference in rendering the page village pump page was obviuos. Probably the best is, to use any trick together, paying much more attention to widely used templates and frequently parsed pages than to exotic, rarely used ones. Unluckily for servers, the worse, heavier pages often are the most frequently parsed and parsed again too.. as "village pump" ones; nevertheless they are the most useful for community, so they deserve some servers load. Nevertheless... sometime people tells me "don't us this hack, it is server overloading"... sometimes it isn't, or simply it is a undocumented, unproofed personal opinion. Alex

2011/1/11 Casey Brown &lt;lists(a)caseybrown.org&gt; Yes I got this suggestion.... but when I try new tricks and new ideas, someone often tells me "Please stop! This is server overloading! It's terribly heavy!"; when I try to go deeper into server overload details, other tell me "Don't worry so much about performance". This is a little confusing for a poor DIY contributor ^__^ Nevertheless, some of my ideas will spread over the *whole* it.source project by imitation and by bot activity (so that any my mistake could really have a significant effect; small... it.source is nothing when compared with the whole set of wiki projects...), and there's the risk that a little bit of my ideas could spread into other projects too, so I try to be careful. Alex

On 12/01/11 05:34, Casey Brown wrote: I've always been opposed to that policy. -- Tim Starling

On Tue, Jan 11, 2011 at 4:31 PM, Aryeh Gregor &lt;Simetrical+wikilist(a)gmail.com&gt; wrote: *cough* http://en.wikipedia.org/wiki/Template:Toolserver 24k revisions of pretty useless historical information. http://en.wikipedia.org/wiki/Wikipedia:Open_proxy_detection 80k revisions and so forth and so on.

MZMcBride wrote: Well, if someone wants to change #ifexist, they should change the parser (braceSubstitution) so that they can be done in parallel. So that if you have for instance: {{#ifexist: File:Flag of {{{1}}}.svg|<td>[[File:Flag of {{{1}}}.svg]]</td>}} {{#ifexist: File:Shield of {{{1}}}.svg|<td>[[File:Shield of {{{1}}}.svg]]</td>}} They are performed in parallel, using one LinkBatch, instead of being two separated queries. Nested #ifexist and other cases would still need being checked separatedly, but it would substantially reduce the "#ifexist load". I think that most of them are even on the same "child level".

On 12/01/11 09:31, Aryeh Gregor wrote: Yes. I know that the main reason for the existence of the "don't worry about performance" page is to make such policy debates easier by elevating elitism to the status of a pseudo-policy. It means that sysadmins don't have to explain anything, they just have to say "what I say goes, see [[WP:PERF]]." My issue with it is that it tends to discourage smart, capable users who are interested in improving server performance. Particularly in the area of template design, optimising server performance is important, and it's frequently done by users with a great amount of impact. It's not very hard. I've done it myself from time to time, but it's best done by people with a knowledge of the templates in question and the articles they serve. Taking a few simple measures, like reducing the number of arguments in loop-style templates down to the minimum necessary, can have a huge impact on the parse time of very popular pages. I've given general tips in the past. I think this is an exaggeration. When I optimise the parse time of particular pages, I don't even use my sysadmin access. The best way to do it is to download the page with all its templates using Special:Export, and then to load it into a local wiki. Parsing large pages is typically CPU-dominated, so you can get a very good approximation without simulating the whole network. Once the page is in your local wiki, you can use whatever profiling tools you like: the MW profiler with extra sections, xdebug, gprof, etc. And you can modify the test cases very easily. -- Tim Starling

Just to give an example: i wrote a different algorithm for [[en:s:template;Loop]], naming it [[en:s:template;Loop!]] and I asked for 100 and 101 dots with them into an empty sandbox preview. These are results: Sandbox, empty, preview: Preprocessor node count: 35/1000000 Post-expand include size: 1858/2048000 bytes Template argument size: 450/2048000 bytes Expensive parser function count: 0/500 Sandbox, 2 calls to loop to print 100 and 101 dots, preview Preprocessor node count: 1045/1000000 Post-expand include size: 2260/2048000 bytes Template argument size: 1551/2048000 bytes Expensive parser function count: 0/500 Sandbox, 2 calls to loop! to print the same dots, preview Preprocessor node count: 193/1000000 Post-expand include size: 2300/2048000 bytes Template argument size: 680/2048000 bytes Expensive parser function count: 0/500 Is there really no useful feedback from these data? Really there's no correlation with "server load"? Alex

On 14/01/11 01:41, Alex Brollo wrote: Yes, there is a correlation between all of those values and server CPU time. In particular, the much smaller preprocessor node count implies in particular implies that your version will be much faster. However, I'm not sure how that obtained that result, since {{loop!|100|x}} just expands to {{loop|100|x}}, since it hits the default case of the #switch. When I try it, I get a preprocessor node count of 1069, not 193. Your version is certainly much faster for a count of 5, rather than 100. For 100 repetitions of {{loop!|5|x}}, I get: <!-- NewPP limit report Preprocessor node count: 2201/1000000 Post-expand include size: 1000/2048000 bytes Template argument size: 600/2048000 bytes Expensive parser function count: 0/500 --> <!-- Served by srv199 in 0.646 secs. --> For 100 repetitions of {{loop|5|x}}, I get: <!-- NewPP limit report Preprocessor node count: 31401/1000000 Post-expand include size: 1000/2048000 bytes Template argument size: 15500/2048000 bytes Expensive parser function count: 0/500 --> <!-- Served by srv245 in 5.043 secs. --> An empty preview takes 0.368s, so that implies that your version is about 17 times faster for a count of 5. That's very close to the ratio of preprocessor node counts. This is exactly the kind of optimisation that competent editors like you can and should be doing. -- Tim Starling