Sorry if this is in the archives. It just bit me in a huge way. We
maintain a MediaWiki for internal documentation which means that
usually one or two people "own" a document (meaning that they're
the only ones who contribute to it.) What's the rationale behind not
allowing a roll-back if there's been only one author?
Is it something that makes sense in a Wikepedia context, but not
necessarily in a general context? If so has it been "preffed" ?
Thanks for any info.
-Sam
Have you tried using the ISAPI module, or just the CGI executable for PHP?
Al.
-----Original Message-----
From: Troy Thompson [mailto:tthompson+mediawiki@envisionware.com]
Sent: Tuesday, 14 June 2005 3:10 a.m.
To: FL; MediaWiki announcements and site admin list
Subject: RE: [Mediawiki-l] Windows Apache & IIS vs Linux
Apacheperformancedifferences
I just want to ensure I've not overlooked something in IIS or PHP which
would improve the performance. Has anyone compared Windows/IIS vs
Linux/Apache and found vast differences in MediaWiki performance?
I see really high CPU usage (up to 90%) for our CGI version as well.
Luckily our traffic levels are low so it isn't really noticable to our end
users. I've read mention of FastCGI as an option to get rid of the overhead
in running the CGI module. Has anyone tried this?
Al.
-----Original Message-----
From: Arthur Guy [mailto:arthur@astarsolutions.co.uk]
Sent: Tuesday, 14 June 2005 9:30 a.m.
To: 'MediaWiki announcements and site admin list'
Subject: RE: [Mediawiki-l] Windows Apache & IIS vs
LinuxApacheperformancedifferences
Just to add my bit; I am using php as a CGI and I still get very high
processor usage about 50%.
My system is a little faster so the performance of ISAPI to CGI seems about
the same.
Arthur
> -----Original Message-----
> From: Alistair Johnson [mailto:JohnsonA@rembrandt.co.nz]
>
> Have you tried using the ISAPI module, or just the CGI executable for PHP?
>
> Al.
>
> -----Original Message-----
> From: Troy Thompson [mailto:tthompson+mediawiki@envisionware.com]
> I just want to ensure I've not overlooked something in IIS or PHP
> which would improve the performance. Has anyone compared Windows/IIS
> vs Linux/Apache and found vast differences in MediaWiki performance?
>
>I'm using the ISAPI module. I've not used the CGI on this server.
'a star solutions' disclaimer
The information transmitted is intended only for the person or entity to
which it is addressed and may contain confidential and/or privileged
material.
If you are not the intended recipient of this message you are hereby
notified that any use, review, retransmission, dissemination, distribution,
reproduction or any action taken in reliance upon this message is
prohibited.
If you received this in error, please contact the sender and delete the
material from any computer.
Any views expressed in this message are those of the individual sender and
may not necessarily reflect the views of the company.
We believe that this communication is free from viruses and other
potentially dangerous programmes, but the recipient opens this communication
at their own risk.
We assume no responsibility for any loss or damage arising from the receipt
or use of this communication
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
I'm have been unsucessful at adding a item to the navigation toolbar. I
tried to follow the instructions found here
http://meta.wikimedia.org/wiki/MediaWiki_FAQ#How_do_I_change_the_contents_of
_the_navigation_toolbar.3F)
but the new link shows up as <Juno> and link's url in the status bar
says "--error:_link_target_missing--". This is what my $wgNavigationLinks
array in LocalSettings.php looks like:
$wgNavigationLinks = array (
array( 'text'=>'mainpage' , 'href'=>'mainpage' ),
array( 'text'=>'Juno' , 'href'=>'Juno' ),
array( 'text'=>'currentevents' , 'href'=>'currentevents-url' ),
array( 'text'=>'recentchanges' , 'href'=>'recentchanges-url' ),
array( 'text'=>'help' , 'href'=>'helppage' ),
array( 'text'=>'sitesupport' , 'href'=>'sitesupport-url' ),
);
I've confirmed that I do indeed have a page at
http://tux/wiki/index.php?Juno (tux is the server on our intranet) so I
assume that I'm mis-reading the instructions or something. I tried adding
an absolute URL with no luck either. Perhapse I created the page wrong? I
just edited the main page and added [[Juno]], saved the page, then clicked
on the red Juno link and then edited that page and save it. Anyway, I must
have missed a step or something, can someone help me get this working?
Thanks for your time!
Is there a script or procedure for the automatic rollback of the sandbox
page, as is done in Wikipedia? I mean the mechanism that magically sets
the sandbox back to its virginal state every day or so.
Hi All,
The main page of my wiki has the variable {{NUMBEROFARTICLES}} on it. I'm
having a problem with multiple client browsers caching this page and not
reloading when the variable changes. If I force a reload, the number is
rendered correctly. If I change the wikitext, the page is reloaded.
Otherwise, I can press F5 all day and not get the latest copy if only the
variable has changed. I have verified this with both IE 6.0 and Firefox
1.0.1. I'm running MediaWiki 1.4.1 with a 'recent changes' patch.
Any ideas? Seems like a caching problem with variables. Can I disable
caching for this page only?
Thanks in advance,
Jeff
On the OS side I really don't care, I use the best one for the application I'm running. But lets face it Windows engineers have decided that bigger is better and Linux engineers pride themselves on how small they can go. If you want to run Windows and have it run at full steam you need power, space and RAM. That was my point in comparing technology to hardware. I think that in Web apps like MediaWiki, LAMP is way to go and you only use WIMP if its madated by company policy.
Michael Rhoadarmer, Media Systems Manager
Wheaton College
Wheaton, IL 60187
michael.r.rhoadarmer(a)wheaton.edu
>>> FL <lengyel(a)gmail.com> 06/13/2005 8:56:06 AM >>>
On 6/13/05, Michael Rhoadarmer <Michael.R.Rhoadarmer(a)wheaton.edu> wrote:
>
> It really shouldn't surprise anyone that Open Source software has issues
> on a Windows box, especially 2000 which is running on a 6 year old design.
> The question might be would the same issue be there if you were running
> MSSQL and .NET instead of PHP and MySQL? Also, 512 is a lot of RAM for LAMP
> but its only a light snack for a Windows server. That's our minimum standard
> for office workstations. Still, for a fairer comparison of technology (not
> hardware) I would double the RAM, install 2003, and eliminate all
> non-essential services. I also might try it turning of page files and going
> straight RAM.
>
> Michael Rhoadarmer, Media Systems Manager
> Wheaton College
> Wheaton, IL 60187
> michael.r.rhoadarmer(a)wheaton.edu
>
> Why is building an even bigger server than the one already twice as fast a
"fairer" comparison? How much does the LAMP configuration have to be
handicapped before the WIMP configuration becomes "fair"? The distinction
between "technology" and "hardware" needs further clarification, to put it
mildly. I suppose one should consider the cost. Why spend more for
proprietary systems and hardware (not "technology"!) for worse performance?
FL
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
It really shouldn't surprise anyone that Open Source software has issues on a Windows box, especially 2000 which is running on a 6 year old design. The question might be would the same issue be there if you were running MSSQL and .NET instead of PHP and MySQL? Also, 512 is a lot of RAM for LAMP but its only a light snack for a Windows server. That's our minimum standard for office workstations. Still, for a fairer comparison of technology (not hardware) I would double the RAM, install 2003, and eliminate all non-essential services. I also might try it turning of page files and going straight RAM.
Michael Rhoadarmer, Media Systems Manager
Wheaton College
Wheaton, IL 60187
michael.r.rhoadarmer(a)wheaton.edu
>>> tthompson+mediawiki(a)envisionware.com 06/13/2005 12:20:11 AM >>>
> -----Original Message-----
> From: mediawiki-l-bounces(a)Wikimedia.org
> [mailto:mediawiki-l-bounces@Wikimedia.org]On Behalf Of FL
> Sent: Sunday, June 12, 2005 3:02 PM
> To: MediaWiki announcements and site admin list
> Subject: Re: [Mediawiki-l] Windows Apache & IIS vs Linux Apache
> performancedifferences
>
>
> Question: is this comparison between LAMP vs WIMP implementations
> of the same software being made on molecularly identical hardware?
> The LAMP configuration is about 3 1/2 times faster than the WIMP
> configuration.
The comparison is on vastly different hardware. The LAMP hardware is a
Pentium 3 laptop at 850Mhz, 200MB RAM. The WIMP hardware is a Pentium 4
server at 2+ Ghz, 512MB RAM.
This actually makes the speed of the LAMP implementation even more stunning;
at half the CPU and half the RAM, it's consistently 4 times faster than the
WIMP server.
- Troy Thompson
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)Wikimedia.org
http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
I have been trying to add and remove items from the navigation bar but I
can't find out how, I have read through all the different guides on the
MediaWiki site but still can't work out where the links are stored.
Which file stores them?
Thanks
Arthur
<mailto:arthur@astarsolutions.co.uk> arthur(a)astarsolutions.co.uk
'a star solutions' disclaimer
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material.
If you are not the intended recipient of this message you are hereby notified that any use, review, retransmission, dissemination, distribution, reproduction or any action taken in reliance upon this message is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of the company.
We believe that this communication is free from viruses and other potentially dangerous programmes, but the recipient opens this communication at their own risk.
We assume no responsibility for any loss or damage arising from the receipt or use of this communication