The Sun V240 server hosted by Fastmetrics is now the live TWiki.org web server

We have moved TWiki.org to our own server (with unchanged twiki.org URL) because SourceForge announced that:

> On 2005-05-23, we will be remounting project group directories read-only on the > project web servers (they will remain read-write from the shell server).

In other words, TWiki.org's TWiki would be read-only, not very useful as all would agree I guess.

We got a very generous offer for a free Sun V240 server.

AndreasGlocker, CEO of Fastmetrics generously offers us to host the twiki server at his company for free!

we now have 4 new hostnames to use (they are all pointing at the same place for now)

• main.twiki.org - this is the main twiki host and is the same as www.twiki.org & twiki.org usage stats
• develop.twiki.org - for now the URL to the develop testing twiki is - https://develop.twiki.org/~twiki4/cgi-bin/view - i'll simplify this later too
• svn.twiki.org - for now you can check out twiki using svn co https://svn.twiki.org/svn/twiki/trunk
• sun.twiki.org - the new Sun V240 server that this page is on - fast huh
• twiki.org has been running TWikiRelease04x01x01 for a while now
• the unauthenticated view script is now running on SpeedyCGI from the blastwave package repository

-- PeterThoeny & SvenDowideit

Great job - thanks a lot!

-- BenoitFauvel - 20 Jun 2005

Good work. This much faster.

Now we have better access as well - meaning we can consider WebDav access and automated mail-out to InterestedParties

-- MartinCleaver - 20 Jun 2005

I can only say "WOW".

Good work

-- RafaelAlvarez - 20 Jun 2005

Peter and Sven; a heartfelt thank you from all of us. I am well aware of the work both of you put in to make this happen!

-- CrawfordCurrie - 20 Jun 2005

The first time I loaded the page about the new server took a few moments to load. Is it possible it could have been Twikied (like slashdotted)?? Congrats and Thanks!

-- MichaelGindonis - 20 Jun 2005

Hey, congratulations for the work with this! I'm sure this new server will improve the work on TWiki even more.

-- AntonioTerceiro - 21 Jun 2005

Yes, I like all this

-- AndreaOlgiati - 23 Jun 2005

CLAP CLAP CLAP CLAP

-- MattWilkie - 23 Jun 2005

I noticed that newly edited topics do not show the new text that was edited until one performs a refresh of the webpage -- like just now when I added via the CommentPlugin, then I added more text via regular EDIT and the same thing happened. I was under the impression that this was an artifact from using the TWikiCacheAddOn, but according to Sven the cache addon has been turned off. So, anyone else seeing this behavior?

-- SteveRJones - 28 Jun 2005

Hmmm, I just added some stuff to the previous comment and the new text showed up with a refresh. The only difference that I see is that I spent a little more time typing.

-- SteveRJones - 28 Jun 2005

testing to see if i get the same thing Steve reports. Added to the comment using edit... - yep, i see the edited text as soon as i hit save... Sorry Steve - I can't reproduce... What browser are you using? (FireFox on Winblows for me)

-- SvenDowideit - 28 Jun 2005

Ok, here goes again -- I am now at home trying this

-- SteveRJones - 29 Jun 2005

Blast it! I swear it did it twice when I first created the entry -- now it doesn't. Yes, FireFox on Win XP Pro - at home and at work. trying to modify this from edit mode . .

-- SteveRJones - 29 Jun 2005

Sven, I can't make it do it again - but I swear I get this behavior elsewhere. Something else I noticed - maybe related - the main twiki.org page does not come through with the CSS applied, but all other twiki pages are rendered correctly. Is the main page a regular web page?

-- SteveRJones - 29 Jun 2005

yeah, the main page is a regular web page - i'll take a look later today (i'll bet that the behavior is reall, and very very cache / net connection dependant)

-- SvenDowideit - 29 Jun 2005

E.g. Microsoft ISA server has a problem with twiki.org, (often) showing a cached view after save. Perhaps a (default/hidden) proxy at work makes the difference between the different browser behaviour at home/work, Steve?

-- SteffenPoulsen - 29 Jun 2005

This could very well be the source of the problem - we do sit behind MS proxy servers at work - and at home I do not

Strange thing is, I never saw this behavior until the temp server came online, then when the new V240 came online the caching behavior got better but never went away completely.

-- SteveRJones - 29 Jun 2005

This server is starting to feel the load, so i've begun a more detailed investigation (i was hoping i had a few more months)

one stat that is interesing, is the total Bandwidth used to serve pages - this is the top 41 - the last column is the total Bandwidth use to serve the page over the last 24 days (attachements, images css inclusive i think)

the total BW used for this period is 31GB - more than all of July

-- SvenDowideit - 25 Aug 2005

Could we just disable the tzdate program? It's a nice service to provide but it's using a lot of bandwidth, and there are many other 'show current time' services on the Internet.

Also, why not use SourceForge for software distribution now that we have NoRegisterDownload? It has a huge network of mirror sites and will also enable our downloads to register on the SourceForge statistics reports, helping increase visibility of TWiki.

Re the proxy cache issues mentioned above - see BrowserAndProxyCacheControl and in particular ViewAfterSaveCachesOldPage, this is a known problem that needs some cache control work to really resolve. There was a lot of discussion about this on TWiki in the past, most of which should be linked or backlinked from BrowserAndProxyCacheControl. Getting this fixed would help quite a lot with deploying TWiki on large intranets that use internal proxy caches at remote sites, as well as improving Internet scalability.

Another approach to scalability is doing a reverse proxy cache (near or on the TWiki servers). This is partly what enables the WikiPedia site to scale to enormous volumes, though they do also have more hardware and more system admin people.

-- RichardDonkin - 03 Sep 2006

Above starts are outdated. Here are up-to-date stats for Aug 2006:

The biggest bandwidth use is by the TWiki zip and tgz packages. Bandwidth is not really the issue, the biggest issue we have on twiki.org is CPU usage caused by the cgi scripts.

The tzdate program is a useful utility: It also brings new traffic to twiki.org, free PR in other words (see twiki ad at https://twiki.org/cgi-bin/xtra/tzdate. A long time ago I reduced the size from 35.58 KB to 2.57 KB and removed the images, so bandwidth is not really an issue (it is page number 32 by bandwidth). I also blocked the abusers, reducing the number of views from 149K to 36K.

We need to improve the performance of twiki.org. People evaluating twiki get a negative firts impression if twiki.org is slow (they do not know that twiki.org is much slower than a typical TWiki installation). Low hanging fruits to improve the performance is (a) newer hardware, (b) caching content for TWikiGuest users. The biggest traffic is by spiders and WebRss pulls.

-- PeterThoeny - 03 Sep 2006