On Feb 16, 1:21 pm, Måns <[email protected]> wrote: > What are the limits on current hardware? > - expected activity/size in a year or so? (-more or less binary files etc > .. -eg. division into more spaces - communication between different > servers??)
It's hard to predict on these sorts of things as there is almost always a bend in the curve when performance degradation switches from linear to exponential. For common requests (e.g. for a single tiddler or a small wiki) there's a great deal of room left in the current server. It's for rare situations where things get a bit problematic (e.g. generating a list of all tiddlers edited today, when someone has PUT 50,000 tiddlers into a bag). Those situations can stress the server quite a bit, especially if several of the same request happen at the same time. We continue to work on improving the situation for both the common and rare situations. Fixing the rare stuff is challenging but not impossible. The @tscount space, http://tscount.tiddlyspace.com/ has some graphs that show growth since the start of the year, but these too are not very illuminating: I don't think TiddlySpace has yet broken out to a wide audience, so I would hope to see quite a change in growth. Whether the proportion of binaries changes has a great deal to do with how the system evolves to present itself to first time users, and what verticals people build into the system. The social discourse aspect pushes towards textual tiddlers while "online notebook" is perhaps more diverse. It will be interesting to track. I can say that the current data storage and search is optimized for text or other small things. It is _not_ efficient for doing things like storing movies or music. Far better to store links to those things. The current server has about 4GB of RAM. This was raised from about 1.8 shortly after the database migration. This was done to allow large caches for both mysql and memcached. The expectation is that we will need more RAM long before need more CPU or disk space (enhanced caching means that less processing is needed to build entities, so when memory was increased cpu usage decreased). When it is time for more processing power the easiest thing to do will be to move to two or three servers instead of one: one or two web servers, each with memcached, and a mysql server. TiddlyWeb has been designed from the start to be state and session-less so a series of requests do not need to go to the same server. In theory this means there can be N tiddlyweb servers operating against the same data store which is replicated across multiple database servers. This is the "horizontal scaling" concept that is considered best practice for webby things these days: instead of making one machine really powerful, use lots of small machines. When it does come time to have more than one machine I will lobby to switch from using virtual machines to real hardware because IO handling on virtual machines is far too unpredictable and tweakable. I reckon this is quite a ways off though. For people who are considering hosting their own tiddlyspace setups, for a small installation nothing like the above is required, especially with effective configuration of the machine and its services. By default many Linux distributions come with apache2 configured in a reasonable but memory hungry way. If you want to save memory for your mysqld and memcached, then use apache2 in a threaded, not prefork, manner and turn off PHP (unless it is being used for something else of course). Long term there is hope to build federation into TiddlyWeb (TiddlyFed?) which will allow one TiddlyWeb (and thus TiddlySpace) server to use content that is stored on another. The primary lever for this will be being able to use remote URIs for bags in recipe lists. There are several hurdles to overcome first. The two that leap to mind are doing effective caching of the remote content and handling authorization. On the latter I expect some kind of OAuth thing will be necessary. I've done experiments with all this stuff in the past but nothing has yet gelled enough to be useful. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywiki?hl=en.
