WikiQueer:Don't worry about performance

The Aequalitas Project is a small non-profit organization, and like most nonprofits, it is perennially short on cash. Therefore, site performance may not always be what it should be: the site may be slow, it may act strangely, it may even crash. But you, as a user, should not worry about site performance. In most cases, there is little you can do to appreciably speed up or slow down the site's servers. The software is, on the whole, designed to prohibit users' actions from slowing it down much.

Wikimedia pays people to worry, so you don't have to
WikiQueer's Operations Working Group includes experts running MediaWiki installations of all sizes - including those powering Wikipedia. The group also actively contributes to the develop of the MediaWiki software powering WikiQueer. WikiQueer's systems, and the MediaWiki software which runs on it, has been designed to minimise editors' ability to affect the performance of the site. More importantly, running MediaWiki to host WikiQueer's sites is what the cluster is for; so editors should do whatever they feel they need to with the software in order to further the project's goals. Performance is not a reason to avoid using redirects, stop linking between pages or avoid editing altogether. The servers would 'perform' best if there was no content on WikiQueer at all, but they would not be achieving their purpose.

If the sysadmins identify a performance problem, they will fix it
WikiQueer's Operations Working Group has access to a wealth of profiling, logging and administration data which allow them to easily identify performance bottlenecks. If a feature of the MediaWiki software is causing unacceptable performance on the cluster, MediaWiki developers will take appropriate action to fix it. Examples of limitations introduced to avoid performance issues are the limitations on template inclusion, the block on deleting pages with more than 5,000 revisions, and the 2Mb maximum size of pages.

Some remedies made by sysadmins are not technical blocks, but 'ordinary' wiki edits. If a sysadmin makes an on-wiki change because of performance considerations, do not reverse it nor block him; equally if a sysadmin tells you to make a change, listen to them.

Editors cannot break the site, only sysadmins can do that
In a few cases, there are things administrators (sysops) can do that will slow down or crash the site. These are, however, rare and not generally worth worrying about; although there are a few things admins can do maliciously which are very difficult to clean up, it shouldn't ever be possible to do something which will result in permanent data loss or unfixable breakage. On the rare occasion something spectacular occurs, follow instructions from the sysadmins who come in to pick up the pieces, and everything will be fine. Obviously you shouldn't do exactly the same thing again, but don't be afraid to do similar things. If you get chastised for trying to delete WikiQueer:Sandbox and crashing the site, don't try to delete the same page again, but also don't fearfully count the revisions of every page you want to delete. This damages WikiQueer far more than a minor temporary slowdown. If you're unsure about something, you can ask a sysadmin on IRC if it makes you feel better, but generally it's not necessary.

Editors still have a role to play
Nothing in this page is to say that editors should not be mindful of performance, only that it should not limit project development. Worry about performance if you can tell the difference yourself. If you find that a page takes ten seconds to load, and takes only one second to load if you remove a particular template, and you can reliably reproduce this and other editors confirm they can too, then obviously the template is slowing down that page. If you would like the page to load faster, then by all means simplify or optimise the template. You won't be measurably affecting the overall server performance either way, but you can still weigh the costs and benefits for an individual page, if you can measure them. Equally, in some areas the developers have provided tools with which you can more accurately measure performance, such as the template expansion limits. In these cases, editors can certainly make use of these tools to improve the performance that they can measure.

As such, these principles mainly cover site-wide performance, where the purpose of the servers is to support the wiki contents, not the other way around. The purpose of the wiki content is to serve the reader; and performance considerations can certainly play a part in that process. Using thumbnails with a large size in bytes instead of a smaller size in bytes (e.g., using a high-fidelity 50kB PNG instead of an uglier 20kB JPEG) can definitely slow down the loading of pages; but whether that's acceptable is an editorial choice, not something the developers or sysadmins will either prevent or encourage.

In short
Be proactive in optimising things where you can measure and quantify a performance impact. Do not worry about the performance implications of things that you can't measure; WikiQueer has an Operations Working Group who will worry about site-wide performance.