Tags:
extract_idea1Add my vote for this tag create new tag
, view all tags
It would be nice if view.pl did a just-in-time compile of wiki pages to html (as it currently does), and keep the cached version around until either the content changes or any of the perl scripts or other configuration stuff has changed. That way, the content would almost always be ready to go and never out of date.

Along the same lines, it would be nice if twiki supported the http thing where pages are sent only if changed (maybe it already does) and even put a 3 second (or more) time-to-live on the request.

Optimizations are probably most important on rss pages.

-- DougRansom - 08 Jan 2003

You might look at LastModifiedFieldOfHttpHeader, which appears to provide for client-side caching. Server-side caching of generated HTML would be an even further improvement, however.

-- WalterMundt - 08 Jan 2003

Check out CacheAddOn. It does server-side caching of the generated HTML. We have been using this at our site for a couple of months, and it is great. Pages return almost immediately. The one problem is we (very rarely) get half-complete pages if the save is interrupted while it is writing the html cached version.

-- MartinWatt - 09 Jan 2003

What we really need is a cache that only caches the 'bit in the middle", so to speak. Unless the cache works across a group of users who have different settings, its not a lot of use and may actually have negative consequences. As an example: suppose I have a customized SeeSkin that's set in my own Topic and you're using a 'vanilla' skin seetting. As MattWilkie points out in SeeSkinDev#Content_before_structure_ even the order of the items of the page might be presented in a different order.

Please note: I do not mean skins using the "url?skin=" syntax, I mean defining it in your Topic page with a "Set SKIN =" statement, so that it does not appear on the URL.

If the caching is tagged only by the Web and Topic then you might get my view of things and I might get yours, which would be most unsatifactory. Please note: I've chosen skins as that is the most obvious example. There could be many others. Plugins such as AgentPlugin or ConditionalPlugin that might vary the output depending on the TwikiUser could also cause problem.

A cache for a single user is useful, yes, but only if the user is going backwards and forwards. If the user is progressing though the "maze of twisty passages" of the wiki, then the cache is an overhead. Better it be implemented in an external proxy cache such a Squid.

We have to think in terms of what is useful to the end user as a user. Yes, speed is important, but the moment it starts being dependant on the user doing certain things, it becomes questionable. Telling users they can't use a skin they want is not going to be viewed as an improvement. Having a page suddenly appear in a different skin is going to annoy users and they are not going to be appreciative of it arriving faster.

Perhaps moving to "complied perl" would be a better solution.

-- AntonAylward -- 09 Jan 2003

I guess it depends what your priorities are. For us different skins are not an issue. We just installed one skin and customised its appearance to match our corporate look and feel (which is actually a very important way to help with the topic of HowToGetInternalBuyInForTWiki - making the skin match the company's graphics styling as closely as possible.) We did tell people they could use other skins if they wanted to, but nobody has chosen to do so. The customisations we have made to the default skin outweigh any benefits from using a different skin. We have not run into any other problems with the caching.

-- MartinWatt - 11 Jan 2003

Granted.

But not everyone is in such a fortunate situation. Even some corporate settings have disfferent "looks" for different sections. MegaTWiki illustrates some of those. Elsewhere we have TWiki supporting multiple disucssion forums ....

But more to the point, what are we really discussing here? If its performance, then things like the set of ModPerl topics and, as I said, using the precompiled versions of perl scripts is going to have a greater impact than caching. To say nothing of being easier to implement and a more general solution.

We should also differentiate the issues surrounding getting buy-in for a wiki. On many of the mailing lists I'm on there are heated discussions over wether a mail interface or a web-based interface is better. Neither side seems know what a Wiki is frown To them a web interface is something like Slashdot! No linking, no ability to re-factor, no search and index capability ...

So corporate buy-in and "forum" buy-in can well have different drivers and issues. The ability to customise skins and colors on an individual basis seems much more important in a forum setting.

Like the saying goes, YMMV.

-- AntonAylward - 11 Jan 2003

Interesting point about caching of differently-skinned pages - this would also affect proxy-based caching, discussed in BrowserAndProxyCacheControl - this talks about how TWiki could affect caching of content through use of HTTP headers. There may be something that could be done with the ETag header, which I think lets you state that a page is different to another page with the same URL, by varying the value of the ETag (entity tag) header - however, it's a long time since I looked at this.

In any case, caching and ModPerl are both valid options for improving performance, depending on requirements and other constraints - in some scenarios, one or the other may not be possible. While ModPerl is the most complete solution to improve performance, it can be harder to configure and requires Apache admin rights. SpeedyCGI has similar issues and was not easy to get working in my experience.

-- RichardDonkin - 13 Jan 2003

Ad skins: The CacheAddOn (obviously) can handle customised skins per site, web and parameter. To SetSkinViaUrlPath you need a workaround script setskin I'll post over there.
If you need personal skins, it is not an option. In my environment, nobody cares to tinker at that level. Either it looks good out of the box or...

BTW: search all TWiki users setting a skin = 38 of 4820 -- less than 1% of a supposedly (t)wiki technology aware user population...

Ad caching vs. ModPerl: My benchmarks do not support this opinion. How could ModPerl do complex searches on hundreds of topics in the subsecond range? It just pays off with small topics, where the load-compile overhead dominates. Or am I missing sth here?

Ad client side caching: Tried this one. Works great. Unless you edit. Or is it acceptable to force a reload on your browser after each simple save? I wouldn't want to propose this to users...

HTH, PeterKlausner 16 Jan 2003

I agree with the main thrust of your point, however the less than 1% figure for people using something other than the default SKIN might have a lot to do with the fact that very few of the skins are actually available to use on twiki.org.

-- MattWilkie - 16 Jan 2003

I've been visitng the various sites referred to in the many topics on TWiki.org. Most of them have done at least a skin modification.

As for the other issues .... I'd rather optimise the 90% case than the 1% case. Most people seem to read pages following some kind of hyperlinked thread. By comparison, the use of complex searches is low. Without logging built in it is futile to speculate about global search usage patterns, but my own use is normally just one word. Most people follow some kind of KISS principle.

As I said, a cache is effective when there is a community of users all hiting the same topic. With a sizeable community and a number of webs and people meandering, it may well not be worth the effort compared to other speed-ups.

Heck, I've just seen the cost of upgrading (as in junking and replacing) our 1Gig Thunderbirds with 2Gig P4s. Its surprisingly low. The cost of upgrading all the users to 100Mhz Ethernet NICs on their PCs is a lot higher. I suspect bandwidth is more of an issue for many sites than the CPU side of things. And by "issue" I don't just mean cache vs mod_perl. I mean everything that affects the user's perception of response.

But as I say, don't sweat optimizing the 1% case and look to other, more cost effective sources of performance improvement. "Think like a manager, not a technician"

-- AntonAylward 17 Jan 2003

True: probably very few TWiki admins will resist and not tinker with templates and skins.
Not so likely: while users will complain about the look and this and that, few will bother to mess with skins on their own.

True; if your site doesn't need forms, %SEARCHes, %INCLUDEs and all those dynamic plugins, your performance won't be too bad anyway; then mod_perl most likely gives enough speed-up.
But then -- why not a real KISS Wiki:WikiClone in the first place?

About speculating: the benchmark figures supplied in CacheAddOn and CacheAddOnDev should indicate whether it is useful in your environment or not.

About bandwidth: should not be a problem on the intranet. You can measure that for yourself:

  1. click, say, WebChanges
  2. your browser blinks, but nothing happens = the server renders
  3. the header appears = the server is done, wire transmission started
  4. the footer appears = transmission plus local rendering complete
And?

About faster hardware: HW cost make up a small part of TCO. Upgrading to a new PC server for just 2 times the CPU clock? Your managers shouldn't let you do that wink

-- PeterKlausner - 19 Jan 2003

My managers reqire that I do that. That's why they're managers.
You're thinking like a techie, they're thinking like managers...

To them, the servers are an asset on the books of the company, a capital investment that is being depreciated over a 3 year period. At then end of the three years they get junked becuase they can't be depreciated any more. From the POV of tax and financing its better to replace them, even if they are still functional. There's another year to go, but that means that the budget proposals have to be submitted NOW, not at the last minute.

No manager looks good if he's not planing ahead, if he has to say things like "Oh and we need another server that wasn't budgeted for".

This isn't about technology, its about business.

Its not about TCO - that abberation that Microsoft has foisted on us - but the way capital budgeting works and the way tax laws are written.

So long as you fail to think in terms of what business needs per business, all the "cool" technology in the world won't get anywhere.

I've written elsewhere that TWiki is far from being a product so long as its programmer-centric. All the "in-band" management such as META and access control may be great for the hackers in us, but is less than apealing for a professional product.

As for "speculating" - I meant you were speculating about sites that are beyond your control and ability to measure. What you are doing amounts to "proof by assertion".

As for bandwidth, thank you for the switcheroo. Not all Wikis are on intranets, not all users are on intranets, cable or DSL.

But as for the KISS - yes I agree. The real problem with TWiki is that its so seductive, all these plug-ins and ability to dress things up!

- AntonAylward - 20 Jan 2003

Edit | Attach | Watch | Print version | History: r13 < r12 < r11 < r10 < r9 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r13 - 2006-02-15 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.