A More Scalable ScrewTurn Wiki Membership Model

I was scratching a scalability itch wondering how ScrewTurn Wiki configured for file-based user storage would perform in a community of 100,000 users. The result was a new approach to Sueetie-ScrewTurn Wiki Membership as described in the new Sueetie Wiki Document republished for you below.

Having worked with ScrewTurn for over a year, I’m confident it could handle 100,000 users with its default file storage provider, but like I said, this was an itch I wanted to scratch, nothing more.  Before going any further, yes, ScrewTurn has a SQL Provider, but Sueetie likes the File Storage Provider. We can talk about why on another post.

To summarize the new Sueetie-ScrewTurn Membership model detailed below, ScrewTurn Wiki accounts are created only when they have to be, to perform functions that very few community members require: authorship and document discussions for example. As a result the load on ScrewTurn for membership handling is drastically reduced. Any non-ScrewTurn specific user functions are handled through Sueetie ASPNET Membership.


Sueetie is member-centric with loosely-coupled applications. Members are known to all applications, while applications run independently of one another. The Sueetie Framework wrapper pulls everything together. In the case of ScrewTurn Wiki membership, you now have the option of relaxing the member-coupling between the Sueetie Framework Membership tier and ScrewTurn’s Membership schema to improve performance and scalability in larger communities.

ScrewTurn Membership Design

ScrewTurn uses a file storage model for all application data. The file data storage area is located in /[wikiapp]/public by default. This works great as you can see by the performance of the ScrewTurn Wiki here at Sueetie.com, but if you have a community of 10’s of thousands of members, relaxing the relationship between Sueetie membership and Screwturn membership may boost your wiki performance and enable you to scale your community to become even larger.

Here is a screenshot of how wiki users are stored in /[wikiapp]/public/users.cs. It’s an efficient storage design. One of the design features that makes ScrewTurn so efficient is that it reads all users into memory rather than regularly retrieving user information from disk. For larger communities, the more we can do to reduce the size of this cached user list the better.


Another file storage-related issue we would want to address is local wiki user group handling. User group information is located in /wikiapp/public/groups.cs. The file consists of a list of groups (highlighted below) followed by a delimited list of all users in that group. Below is a screenshot. Like the users.cs file, this data is cached for performance. The design of lines of delimited group-users to be read and parsed works great, but the idea of using this approach for a community consisting of 10s of thousands or 100s of thousands of users is untenable.


What we gain and how we gain it

How do we gain this member performance and scale bounce? Simply put, we do not create membership accounts in ScrewTurn Wiki by default when they join the community. Community members are still known in the wiki by their ASPNET-based Community Membership authentication and displayed on the page banner and elsewhere. Only the functionality is reduced to ScrewTurn Wiki capabilities needed by wiki power users only. We’ll discuss those functions in a bit.

What do we gain by our more loosely-bound Sueetie/ScrewTurn Wiki Membership model? Let’s try this comparison of community-to-wiki member requirements. Our community can consist of 1000 members, while with our more loosely constructed membership model, the membership load our wiki carries may only be 50. Or try another comparison: a Sueetie community of 100,000 members can have a ScrewTurn membership load of only in the 100’s. Where do I get those numbers? They are based on the functions for which community members will request a Wiki member account, and only a very small percentage of community members will have a need for those wiki member-only functions. And the functions? Document discussions, update email notification support, view restricted documents or author documents. Otherwise, members will experience a Sueetie wiki for all UI and functional purposes as a fully-authorized wiki member.

Authorship and restricted document access

If your Sueetie Community Wiki contains restricted documents that only registered users can view, then this model would not be applicable. Community members would need to be known to ScrewTurn Wiki to enjoy authorship or restricted document access. It’s my experience, however, that most Sueetie Communities use a very limited group of authors to produce wiki documents and that all documents are available to view to both registered and anonymous users. This is the type of community wiki construction that benefits from the loosely-constructed membership model.

Document Discussions and the Sueetie Community Member

Document Discussion support is a ScrewTurn Wiki feature that I think is simply fantastic. In most environments it simply isn’t used. It certainly doesn’t get much use here on the Sueetie.com Wiki. How the loose membership model accommodates discussions is shown below. The [Discuss] link is shown on all documents as normally. When an non-wiki member clicks on the discussion link he or she can view the discussions but there is no "Post a Message" link. Instead, a message is shown to the Community Member that they need to contact the site administrator to enable their member account for document discussion support.


Document Email Notifications

Only known ScrewTurn Wiki users can configure their accounts to receive updates of wiki documents by email. They configure this through their ScrewTurn Wiki Member Account page. What happens with the loose member model is that rather than the user’s wiki account name being displayed in the header, the Community Member’s name is shown. Otherwise "guest" would be displayed as the username. (Sueetie adds a {SUEETIEUSERNAME} format tag in /public/header.cs and a new handler in the Wiki.Core.Formatter.cs.)


Upon clicking on the user profile link, instead of the guest default page displaying, a Sueetie-specific page is shown with the email notification and wiki timezone setting function along with a similar message as before instructing the Community Member to contact the site administrator to upgrade their account to support document update email notifications.


RSS support is deeply embedded into ScrewTurn Wiki, so document update email notification is really overkill anyway. On each page you can subscribe to that page (so you’ll receive all page updates via RSS instead of email), you can subscribe to the entire library, or you can subscribe to that page’s discussions. Pretty great.


How to Create Wiki User Accounts

A ScrewTurn Wiki Account feature enables Sueetie Community Administrators to quickly create wiki accounts.


What if I don’t want this "loosely-constructed" membership on my Sueetie Community?

By default, a wiki account is created for all community members when they register. If you want to implement this model of wiki membership to enhance performance and scalability of your community down the road, simply uncheck the "Create Wiki User Account" on the General Site Settings Administration Page.


Article written by

A long time developer, I was an early adopter of Linux in the mid-90's for a few years until I entered corporate environments and worked with Microsoft technologies like ASP, then .NET. In 2008 I released Sueetie, an Online Community Platform built in .NET. In late 2012 I returned to my Linux roots and locked in on Java development. Much of my work is available on GitHub.