Hacker News Reader

Comment by misode | Hacker News Reader

The Mediawiki software is not a static webpage

Mediawiki is trivial to cache, though. For all intent and purposes most hits will be cache hits, and thus "static" content.

I'm also shocked at the tens of thousands per month, it can't possibly be hosting alone. It has to be that the maintainer had a generous salary or something.

Seriously? How does that even make sense to you? The OP had an asset generation 10k+ a month in profit and was so squeezed for cash he had to sell it.

Doesn’t it make more sense that a media have site would have been paying through the nose for bandwidth, hence the callout for cloudflare which would have made that cost free?

I could have the numbers wrong, archive.org is down otherwise I would check as we shared information publicly at the time. As far as I recall, we weren't taking money from the websites, we were spending on infrastructure alone with more than $10k in spend in the final month before the sites were acquired. I think it is easy to forget how much more expensive running things on the internet was back then along with the unprecedented popularity of Minecraft. Once archive.org is back online, I'll track down numbers.

Not everyone is a professional web hoster with requisite knowledge on how to setup caching properly.

Mediawiki involves edits that users expect to propagate instantly to other pages. Sometimes this can easilt result in cache stampedes if not setup carefully.

MediaWiki supports extensions. Some of the less well architectured extensions add dynamic content that totally destroies cachability.

Everyone is better off learning how to setup caching properly than continue to pay tens of thousands dollars per month. It's not rocket science.

> Mediawiki involves edits that users expect to propagate instantly to other pages. Sometimes this can easilt result in cache stampedes if not setup carefully.

Most users should not even be hitting MediaWiki. It's ok to show cache entries that are a couple of seconds or even minutes out of date for logged out users.

> MediaWiki supports extensions. Some of the less well architectured extensions add dynamic content that totally destroies cachability.

Again, nothing reasonably needs to update all that often.

> For all intent and purposes most hits will be cache hits, and thus "static" content

That's not what static means in the context of hosting. Static means you upload files by FTP or WebDav or some other API and that's it. Something like hosting on S3. If users can log in, even if they usually don't, it's nothing like static any more.

I have no idea how it works, but given that the read:write ratio is probably 100:1 or more, certainly it could just serve static, prerendered pages straight from the filesystem or something like memcached?

[Im a mediawiki dev]. Typically people use varnish for that use case. MediaWiki does support serving logged out views from a filesystem cache, but varnish is generally a better idea. There are also some caches out of memcached (mediawiki has "parser cache" in memcached which is the part of the page that stays constant between all users. Typically people use varnish on top of that for the entire page for logged out users)

Sometimes people add things to their sites that are incompatible with caching, which will make hosting costs go way up.

Thanks!

Reply on news.ycombinator.com