Month: April 2011

fastest foswiki (and TWiki) ever – MongoDB for foswiki milestone 4

When the foswiki on MongoDB project started, this query would take 5.4 seconds to provide the html to the client (pure CGI), now it takes 0.7seconds (with mod_fcgid).

Thats a speedup of over 7 times.

I realised today that I’ve not written up a progress post for foswiki on MongoDB for a bit – and so did a few benchmarks again.

The benchmarks given (at http://foswiki.org/Development/MongoDBPlugin ) are for a structured query on a DataForm based web containing 25,000 topics, and are run on a desktop system running a 1.8GHz core2duo with 2G RAM.

When the foswiki on MongoDB project started, this query would take 5.4 seconds to provide the html to the client (pure CGI), now it takes 0.7seconds (with mod_fcgid).

That’s a speed-up of over 7 times.

Many other large web queries, like a WebIndex on a large web couldn’t even complete before, and now run in a usable fashion.

This milestone we’re separating out each web into its own database, and I’ll be adding in the topic revision information to the database too – that way it won’t matter if you have 10,000 webs, or 1,000,000 – the speed should be essentially constant (so long as you have the server resources to match your loads).

 

If noSQL isn’t suitable, and you would like to see a similar back-end developed using an SQL engine – contact me – WikiRing and fosiki are looking for interested companies with foswiki (and TWiki) scaling issues – without real life testing, examples and stakeholders, its extremely difficult find the many corner cases that our complex engine can allow.

Sharepoint 2007 to foswiki migration project part 1

I’ve spent the last few days working on getting data out of Sharepoint Wiki, and its shocking. If you read the webservices API and believe it, things would be simple.

I’ve spent the last few days working on getting data out of Sharepoint Wiki, and its shocking. If you read the webservices API and believe it, things would be simple. Sadly, its got some pretty major bugs, and some pretty woeful architecture too.

The worst finding is that although Sharepoint lists have a webservice API to get versioned data, its broken – all versions of the MetaInfo return the text of the last revision. So I had to resort to brute force html GET’s and parsing the html to try to get the historical info.

Still, data gathered and saved – next week I’ll start trying to extract the valuable user written text from the masses of shoddy html (like in MS Word to html, every line is surrounded by the same 100 character css styles, setting font to Verdana etc.