> From: Tomasz Wegrzanowski <taw(a)users.sf.net>
> I tried some search on Japanese Wikipedia, which was of course off,
> and I was redirected to the Google. But the problem was - the request URL
> didn't contain encoding information.
Does now. :)
Thanks for the note...
-- brion vibber (brion @ pobox.com)
I tried some search on Japanese Wikipedia, which was of course off,
and I was redirected to the Google. But the problem was - the request URL
didn't contain encoding information.
&ie=UTF-8&oe=UTF-8 should be added to the request URL.
Something that just popped into my mind... separating history. IE, once
we're in multiple-server land, have:
A) Read-write server(s)- sent to when you click an edit link
B) Read-only servers for primary viewing - no old versions of articles
stored (or just a couple recent ones)
C) Read-only server(s) with history - sent to when you click page history
(or a diff link somewhere)
B being the new bit that came to mind, thinking about the tendency of
database performance to degrade based on size.
Just a random thought.
-- Jake
Please don't put alterations to the database structure into update.php. In
fact, please don't use update.php at all. I don't know why it exists, and
would advocate deleting it.
Database alterations should be in clean, separable text files containing
runnable, human-readable SQL statements. They should be called
"patch-XXX.sql" where XXX is a descriptive word. They should go in
maintenance/archives. patch-list.txt there should include a description of
the problem it solves and instructions on what it's all about.
If update.php is to be saved, it needs to be rewritten to not make a mess
of things and use only these clean, legible, standalone files.
-- brion vibber (brion @ pobox.com)
Hello,
new version (1.31) of LanguageDe.php in CVS.
Smurf
PS: If someone can apply the fix mentioned in
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/006106.html
we could be back in Multi-Lingual-Mode for the Watchlist ;)
--
Smurf
smurf(a)AdamAnt.mud.de
------------------------- Anthill inside! ---------------------------
Hopefully I have the right list now...
I was a developer a while back for the (purportedly) 17th busiest website in
the world and though the sysadmins were more directly involved in improving
response speed, I ended up doing a lot of stuff myself. The way that
Wikipedia is slow is very similar to problems we had. The delays are almost
all in the initial request for new pages. Once the connection is made,
content usually comes across rapidly. This usually points to some sort of
full queue in software, or a full queue due to excessive connections on a
single machine causing a hardware wait state. New url requests are made to
stand in line, sometimes because settings for maximum simultaneous
connections are too low, or the settings are high enough but all RAM is
consumed servicing current requests, etc,. This may seem obvious, but it
lets us de-emphasize other potential problems such as bloated overworked DB,
bogged disk fetches, etc. So, based on all this, I would say the greatest
single improvement would be to set up some sort of simple DNS round robin
(true load balancing could come later). I'm not sure what your current
server setup is, but if you could have at least two Apache servers running
on two machines with one of them running the Round Robin algorithm I think
the majority of your response problems would disappear. Don't listen to
those who say Round Robin is a naive approach. It's true that allocation of
new connections is done in a "dumb" way (in a two server setup it will just
throw every other connection to the secondary webserver)-- but that's all
you really need, I think. Suddenly each machine is servicing half the client
connections and everything is fast... Of course, maybe the reasons for your
slowness are more complex, but based on what I can see from the client side
my suspicion is that a simple Round Robin would clear it all up and that
simply adding new Apache processes on new servers as you grow would make you
at least 10 times faster during peak times than at present. -- JDG --
Hi,
when the page is loaded, and one clicks on "next 50" (or what it is
named in english) it really shows the next fifty contributions
starting from #101, not #51.
Regards,
Nils.