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