For a few glorious days, I had sysop status. I no longer do. Magnus
knows at least a little about the problem, but if any of you know as well
and can fix the problem, that would be great.
The problem might be related to a login problem we still have. When I go
to any page and press "Log out" and then "Log in", I come to a page that
says: "User Larry_Sanger1, you are already logged in!"
If I then attempt to log in as "Larry Sanger", which I *suspect* (don't
know) has sysop status (whereas "Larry_Sanger" does not), it tells me:
"Larry Sanger, you are logged in!" Moreover, the link in the upper right
hand corner is to "Larry Sanger"'s homepage. Hopefully, I then go back to
the Main Page only to find that I am once again "Larry_Sanger" (so says
the upper right corner link) and do not have sysop privileges.
I am running the current CVS version locally and updated my database
scheme. Search, RecentChanges, edit and preview works fine, but if I
try to save my changes, they are all lost and the file is back to the
previous version. It doesn't happen for all files, and I don't know
what the difference is (two example problem files are the main page
and "British Queen"). It's not a browser cache issue, since when I try
to edit the page again, the wiki text is also reverted to the old
version. I can write to the database, since the page counters change
correctly. Does anybody see that problem?
Axel
With my new checkin permission, I went to work happy as a clam.
I added a README file and the GPL license in COPYING.
The file wikiTextEn.php uses the $THESCRIPT variable, and it therefore
has to be included at the end of wikiSettings.php, after
wikiLocalSettings.php has been read. I made a new variable
$wikiLanguage which can be set in wikiLocalSettings and which
determines which wikiText file is included later.
Axel
On mer, 2002-02-13 at 17:24, Jimmy Wales wrote:
> Brion Vibber wrote:
> > I'm not sure what advantage would be gotten out of storing a version
> > that has had HTML tags worked over, but still needs the wiki code
> > converted into HTML every time we load it. We get more speed by caching
> > the completely parsed version, or more storage savings by reparsing it
> > every time and not storing anything but the the editable text.
>
> It's worth noting that on the live server, I see no material difference when
> I turn caching on or off.
Interesting. I have to wonder whether this means caching is for some
reason not working at all... It seems to be disabled and/or broken at
the moment, unless someone sneaked in and fixed the other-languages bug
while I wasn't looking.
I ran "ab -n 10" on a couple pages running on my test server with
various states: caching on, caching off w/ no removeHTMLtags() call,
caching off with the old removeHTMLtags() code, and caching off with my
new as-yet unoptimized but more secure version of removeHTMLtags(). The
pages per second figures from three trials each:
Beryllium (large HTML table, various other tags)
* cached 2.06 2.06 2.16
* none 0.94 0.95 0.95
* old 0.90 0.90 0.89
* new 0.47 0.48 0.48
Esperanto-wiki mainpage: (a few <b>, <i>, and <font> tags)
* cached 3.26 3.13 3.47
* none 1.84 1.83 1.76
* old 1.82 1.80 1.80
* new 1.58 1.62 1.58
> Also, space is really cheap these days. And we're not in any immediate danger
> of running out of it.
Very true.
-- brion vibber (brion @ pobox.com)
Just as the announcements page says, Wikipedia is a lot faster now.
Thanks to everyone who made it possible. A quick-loading Recent Changes
page is a beautiful thing.
Larry
I just ran "ab n=10" for an atricle (with cache turned off) and deactivated
some functions to see where the slow parts are.
Full rendering : 4.99 sec
removeHTMLtags turned off : 3.319 sec
It seems removeHTMLtags is responsible for 1/3 of the *total* runtime, which
includes apache, php calling, and a thousand other things that can't be
avoided.
So, if these HTML tags are *never* used anyway, why can't we replace them
with < and > just prior to saving an edited article?
I'll be gone tomorrow until Saturday, and I doubt I can hack it today, so
it's up to you...
Magnus
Jan said that I have caching turned off, which surprised me because I thought
it was on. Now I've looked at the code and I still think it is on.
wikiSettings.php:
$useCachedPages = true ;
wikiLocalSettings.php:
# $useCachedPages = false; # Disable page cache
(This is commented out, right?)
-----------------
Playing with benchmarking, grabbing a normal article 100 times:
(I know that this type of benchmarking is not very scientific, since conditions
may change on the live server due to someone else doing something big at the same
time, etc. But I think it gives an indication.)
As the site is running:
/apache/bin/ab -n100 -c1 http://www.wikipedia.com/wiki/Alabama
Requests per second: 0.95 [#/sec] (mean)
Now I will set $useCachedPages to false by uncommenting the line in wikiLocalSettings.php.
/apache/bin/ab -n100 -c1 http://www.wikipedia.com/wiki/Alabama
Requests per second: 0.97 [#/sec] (mean)
So I see no material difference.
How can I easily tell if caching is actually on or off? Am I doing something wrong
here?
From: "Jimmy Wales" <jwales(a)bomis.com>
> Jan Hidders wrote:
> > Can I suggest we simply stop with the whole caching thing? It
complicates
> > things unnecesarily. Keeping the code simple should be one of our top
> > priorities. Jimbo doesn't have it turned on at the moment anyway,
>
> I have no strong opinion about this, but I wanted to say that I
> thought I did have it turned on. If it's off, that's a mistake.
My mistake. I saw that the language links worked, but hadn't realized I was
looking at the page just after I edited it. I see now that you do have it on
because upon reloading the page the language links are missing, so I get
apparently the cached page.
> Tell you what, I'll benchmark with and without, on the live server,
> and report the numbers.
Yes, that would be very very welcome.
-- Jan Hidders