What versions of apache, php and mysql is everybody using? I want to
include the most appropriate versions in the README.
Myself:
# ../bin/mysqld --version
../bin/mysqld Ver 4.0.0-alpha for pc-linux-gnu on i686
http://127.0.0.1/server-status
Server Version: Apache/1.3.20 (Unix) PHP/4.0.6
I suspect that my intermittent database problems have to do with the
4.0.0 mysql and its handling of fulltext indices. I'll downgrade
shortly.
Axel
Hi,
I started my mysqld with --log and found that we are constantly and
pointlessly selecting the wiki database. I combined all those calls in
getDBconnection() and made sure that we only call mysql_select_db()
and mysql_pconnect() when we really need to (i.e. once), using a new
global $wikiDBconnection.
Axel
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)
> > 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 just have two objections:
>
> First, it violates the principal of least surprise;
> the user doesn't get
> the same thing upon a re-edit that they left during
> the last edit. This
> is particularly annoying for people who are putting
> complicated tables
> into articles (cf. [[Beryllium]] and [[Periodic
> Table]]) -- if they do
> one thing wrong, POOF! Half their table <tags>
> suddenly turn into
> <tags> and instead of fixing one tiny mistake,
> they fix one tiny
> mistake AND change a lot of <>s back into <>s.
> Conclusion: bad for users.
>
> Second, enforcing the limited subset HTML is just a
> part of the wiki
> parsing. Doing that on save is fine, but is
> basically doing half the
> parsing job and caching that, then doing the other
> half when we display
> the page. Why stop there, when we could just parse
> the wiki-specific
> code while we're at it and save the final result?
> Conclusion: what exactly is our goal here? To save
> processing time on
> page load? This is most effectively done by caching
> the completely
> parsed version, both HTML and wiki -> HTML.
My first thought when I read this was to have two
seperate versions of the page. One for the server and
one for the editor. Basically when someone saves a
page, this creates an html page and saves a seperate
wiki page. This way all processing would be done only
when someone saves a page rather than everytime
someone loads a page?
Is there a flaw in my reasoning other than the
database doubling in size? I guess it depends on
which is more important: space or speed?
Chuck
=====
Venu al la senpaga, libera enciklopedio
esperanta reta! http://eo.wikipedia.com/
====
Junuloj! Filadelfio, Usono 15an-17an de Februaro
http://unumondo.com/cgi-bin/wiki.pl?Filadelfia_JES
_________________________________________________________
Do You Yahoo!?
Información de Estados Unidos y América Latina, en Yahoo! Noticias.
Visítanos en http://noticias.espanol.yahoo.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