Last modified: 2012-02-21 13:59:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T36519, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 34519 - raise template include size limit on Commons
raise template include size limit on Commons
Status: RESOLVED WONTFIX
Product: Wikimedia
Classification: Unclassified
Site requests (Other open bugs)
unspecified
All All
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: ops
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-19 16:53 UTC by Saibo
Modified: 2012-02-21 13:59 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Saibo 2012-02-19 16:53:12 UTC
The page [[:commons:Commons:Deletion_requests/2012/02]] is in Category:Pages where template include size is exceeded (automatically by mediawiki). that is disturbing our work at commons

Is it possible to get a higher limit for all Commons:Deletion_requests subpages? 
Probably it is just 3 pages being affected so it should not really be a notable increase in load on the servers.

btw: the discussion is here: https://commons.wikimedia.org/wiki/Commons:Administrators%27_noticeboard#Commons:Deletion_requests.2F2012.2F02_is_in_Category:Pages_where_template_include_size_is_exceeded
Comment 1 Antoine "hashar" Musso (WMF) 2012-02-21 09:54:34 UTC
This page already takes 22 seconds to parse and is 830KBytes, that is adding stress to the servers every time a logged in user access it.

For the monthly view, you should only include the page title, not the full page.

If you really want one page showing it all, you should add an additional layer to view deletions requests per week.
Comment 2 Saibo 2012-02-21 13:25:06 UTC
(In reply to comment #1)
> This page already takes 22 seconds to parse and is 830KBytes, that is adding
> stress to the servers every time a logged in user access it.
> 
> For the monthly view, you should only include the page title, not the full
> page.
> 
> If you really want one page showing it all, you should add an additional layer
> to view deletions requests per week.

Then the servers are too slow. ;-)  There is good use for this page and I hope you do not mean that we are no allowed to put load on the servers for working? Is load only allowed for readers?
Comment 3 Max Semenik 2012-02-21 13:28:07 UTC
(In reply to comment #2)

> Then the servers are too slow. ;-)

Nope, you're just pushing to the limit. Even if we expand the limit, people will immediately start inventing other reasons to peg the servers even harder. It has to stop somehere. Please don't reopen just because you disagree.
Comment 4 Antoine "hashar" Musso (WMF) 2012-02-21 13:33:19 UTC
Saibo > that page is indeed putting to much load on the server. That is why we have a limit, to avoid a couple of pages taking all the resources.

The page listed above really need to be split, that will make it easier for everyone (readers, editors, admins and servers of course).
Comment 5 Saibo 2012-02-21 13:59:22 UTC
(In reply to comment #3)
> Nope, you're just pushing to the limit. Even if we expand the limit, people
> will immediately start inventing other reasons to peg the servers even harder.
> It has to stop somehere. Please don't reopen just because you disagree.

Why shouldn't I reopen if I think the bug is not resolved? Sounds right - there is no formal closure by admins here (like at Wikipedia/Commons deletion discussions).

(In reply to comment #4)
> Saibo > that page is indeed putting to much load on the server. That is why we
> have a limit, to avoid a couple of pages taking all the resources.
What means "too much"? Do you have numbers in a sense of CPU time? Which percentage of the total CPU time does this page account for?

> The page listed above really need to be split, that will make it easier for
> everyone (readers, editors, admins and servers of course).
A split will make it not easier regarding a full text search of all open requests of this month using the browser's built-in search.

It seems to me the page creation is not really efficiently done here.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links