It seems that the threshold of "Post-expand include size" comes from the setting of "$wgMaxArticleSize". It is too difficult for me to know the origin of its default value (2MB), and it is very important for DDoS defense, but considering T15260, quoted from Template limits
Note that the sizes of the wikitexts of all expanded templates and parser functions are added, even in the case of nesting (see bugzilla 13260,or phab:T15260), so extra levels increase the count. If page A transcludes B and B does nothing but transclude C, then the size of C will be counted twice towards the post-expand include size on page A...
The "Post-expand include size" is twice as many bytes as the source code should actually be after expansion, which seems to be a common phenomenon and is beyond the strength needed to defend against DDoS.
Take zhwiki (the wiki project I work on) as an example:
- In T228716#6802694, ' https://zh.wikipedia.org/wiki/Template:Internal_link_helper/en ' is a warpper with specific language parameters of ‘ https://zh.wikipedia.org/wiki/Template:Internal_link_helper ’, and 'https://zh.wikipedia.org/wiki/Module:Ilh' is implement of 'Template:Internal_link_helper', which I wrote it for improve. The Post-expand include size of the call to "Template:Internal_link_helper/en"( https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E6%B2%99%E7%9B%92&oldid=70073778, 1137 bytes ) are almost twice as large as the count of "Template:Internal_link_helper"( https://zh.wikipedia.org/w/index.php?title=Wikipedia:%E6%B2%99%E7%9B%92&oldid=70073794, 762 bytes ), and the actual count of expand include size ( put the code of the first call into "Special:ExpandTemplates" and directly calculate the bytes of "Result", 375 bytes ) is also almost twice as large as the count of "Template:Internal_link_helper". This looks like serious puffiness.
- The other is Navbox. The use of {{Navbox}} often contains multiple {{Navbox}} as child elements. I additionally reimplemented as {{NavboxV2}} to flatten the behavior of embedding the child {{Navbox}}s into the main {{Navbox}}. According to the test case (mainly for, the child {{Navbox}}s is nested into the main {{Navbox}} ), it can indeed reduce the Post-expand include size by about 50%~60%.
Defending against attacks by limiting input is important, but the side effects of T15260 also appear to be more than expected. So I strongly recommend decoupling the "Post-expand include size" threshold setting from "$wgMaxArticleSize" and assuming that due to the presence of T15260, the "Post-expand include size" will be twice as large as the original code (default value 4MB, which is twice the default value of "$wgMaxArticleSize"), or allow custom settings without affecting the effect of "$wgMaxArticleSize".
BTW, I also hope that someone can continue the investigation of T15260, why is it twice, and where is the problem? I've heard that the foundation's back-up funds are abundant, and I hope these funds can be spent in more appropriate places.