Brion Vibber wrote:
Timwi wrote:
I'm not sure that is such a good idea, performance-wise... ideally, it should go straight to the correct URL. People would otherwise constantly use "Copy link to clipboard" on these links and fill the web with nonsense links like http://de.wiktionary.org/fi:Kukkala, and we would forever have to keep the redirects working. They are starting to become a little difficult to keep track of, and I'm afraid it's only a matter of time until we will inadvertantly create an infinite loop of redirects somewhere.
One chief reason for making these links available is to allow interwiki linking from *non-wikimedia* wikis as well. By using a single established prefix (WikiPedia:) you can link to any of our languages without begging third party site admins to add three hundred prefixes to their interwiki maps.
This is a fair point, but nonetheless an implementation that I'm not entirely comfortable with. (Admittedly, I can't think of a better one other than to encourage the entire wiki community to go entirely multi-lingual and have all wikis standardise on a [[<sitename>:<langcode>:<pagename>]] syntax for links to other wiki sites...)
Another major disadvantage I thought of just now is that it poisons our namespace. Suppose some silly company makes some sort of product and (to be cool) calls it "fr:ea:ky". How would we name our article on it? It's only a matter of time until this will be an actual problem.
For those who don't already know what's so bad about redirects: (1) Even just one redirect doubles(!) the server's response time.
That's not exactly true; the redirect bounce doesn't require rendering, and if appropriately set up can be cached at the squid level.
At the time I wrote the previous message, my experiments with Telnet showed that the server took several seconds to reply with the redirects, but returned an actual article quite quickly. (Both are pretty quick now; maybe load has gone down since?) This leads me to believe that these redirects are not currently handled by the squids, and furthermore, that the load on the server is slowing them down significantly even though, as you say, they do not require rendering.
I'm assuming by "rendering" you are referring to turning Wiki-markup into HTML. While such a redirect doesn't need rendering, it still needs processing of an HTTP request. I'm wondering what proportion of the CPU power spent on a single HTTP request (including TCP handling, HTTP request decoding, PHP parsing and execution, and generating the HTTP response) goes to rendering. If CPU usage is the current performance bottleneck, then determining that a link to [[a]] should actually go to [[A]] might be quite as noticeable as a page rendering, as it is overheaded by the entire HTTP request handling and PHP stuff.
These kinds of redirects, admittedly, do not require access to the DB. This point is only significant if DB access is the current performance bottleneck.
Greetings, Timwi