On ĵaŭ, 2002-05-09 at 18:27, Brion L. VIBBER wrote:
> On ĵaŭ, 2002-05-09 at 17:08, Jimmy Wales wrote:
> > I just turned on page caching. Maybe it has bugs?
> With caching disabled, the page cache hasn't been updated in three
> months. :)
> Just clear all the cached pages:
> UPDATE cur SET cur_cache=""
> should do it. (Double-check that before you run it, obviously.)
CORRECTION: DO NOT PEFORM THE ABOVE QUERY!!!!!!!!!! It would reset the
last edited time on every page to the current date!
UPDATE cur SET cur_cache="",cur_timestamp=cur_timestamp
I'm beginning to think those auto-updating timestamp fields aren't such
a good idea.
-- brion vibber (brion @ pobox.com)
FYI, I just changed http://susning.nu/ from plain old CGI to FastCGI
and it really makes a change. This is a UseModWiki, just like the old
pre-PHP Wikipedias. Plain wiki pages used to load in 2.5 seconds on
average. Now they load in less than 0.8 seconds (searches and recent
changes take longer).
Q: Why don't I change to the Wikipedia PHP software?
A: I've invested too much of my own hacking into the UseModWiki script
to abandon it quite yet. And converting to FastCGI turned out to
be a piece of cake.
Q: Why don't I run mod_perl instead of stinking old FastCGI technology?
A: I use a web hotel with Linux shell login accounts and they don't do
mod_perl. I think the reason is that scripts run under mod_perl
cannot change user ID to each customer.
Q: Does the site get any traffic?
A: It had 180,000 page views in April from 40,000 unique IP addresses,
growing at 40 % per month. Many hits are referrals from Google.
It's like a miracle cure.
5:43pm up 37 days, 8:13, 1 user, load average: 0.76, 1.95, 6.84
Compare this to hovering around 100 earlier today.
I did two things -- turned on page caching, and forced
getOtherNamespaces to return an empty array.
The site feels usably fast now, and the load average is a lot lower.
Improving performance on English server: when the
server reaches a certain threshhold of activity could
we replace the text of all the Special pages with:
"This page is currently inaccessible because of the
immensive amount of traffic we're getting. Wikipedia
is just too popular."
Also, has the Lastaj Sxangxoj page on the Esperanto
Wikipedia page been defaulted to 3 days yet?
Come to my homepage! Venu al mia hejmpagxo!
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.com
A lot of the character-encoding stuff in the present code is a mess
too. I understand well and can handle all the details between server
and browser, but two things I don't know all the quirks of are PHP and
MySQL, so this is my attempt to pick the brains of those who have
already found those problems:
(1) Is MySQL 8-bit clean? If I store a chunk of 8-bit bytes in a
text field, will I get them back unmolested, or will MySQL try to be
"helpful" and fuck them up? If the latter, what are the limitations
of what can be stored in a text field and where is that documented?
(2) Are PHP strings 8-bit clean? I'd be amazed if they weren't,
considering how much of PHP is modelled on Perl.
(3) Is the PHP on wikipedia.com compiled with the "iconv" library
(an optional thing), and does PHP use it as documented?
Lee Daniel Crocker <lee(a)piclab.com> <http://www.piclab.com/lee/>
"All inventions or works of authorship original to me, herein and past,
are placed irrevocably in the public domain, and may be used or modified
for any purpose, without permission, attribution, or notification."--LDC
I've been studying performance today. I'm looking for the
bottlenecks. The total volume of traffic on the site is not so high
as to cause me to reasonably suspect that hardware is the problem. So
I'm looking for things that people do on the site that tend to be
expensive, so that we can eliminate features for awhile (if we must)
or find ways to optimize/cache them.
1. I notice that many of the 'special' pages are quite popular. I
suspect that these are our best bets.
2. I propose that we test the site without the "this page has been
accessed N times" feature. Doesn't it seem excessive to have a
database write for every single pageview, when we are trying to
increase performance? A nearly equivalent feature could be provided
with a daily update from the access logs.
I'll go through the source over the weekend and try to find and fix some
For now, it might improve the speed if the MySQL server would be located on
a different machine than the Apache. I think that could be done without too
much trouble, and without security problems for Bomis.
Warning: Supplied argument is not a valid MySQL result resource in /home/wiki-newest/work-http/wikiPage.php on line 86
Warning: Supplied argument is not a valid MySQL result resource in /home/wiki-newest/work-http/wikiPage.php on line 88
I didn't do anything to cause this. I am looking into it now.