(David A. Wheeler dwheeler@dwheeler.com):
- Perhaps for simple reads of the current article (cur), you
could completely skip using MySQL and use the filesystem instead.
In other words, caching. Yes, various versions of that have been tried and proposed, and more will be. The major hassles are (1) links, which are displayed differently when they point to existing pages, so a page may appear differently from one view to the next depending on the existence of other pages, and (2) user settings, which will cause a page to appear differentlt for different users. But caching is still possible within limits, and using the filesystem rather than the database to store cached page info is certainly one possible implementation to be tried.
[Rendering] could also be sped up, e.g., by rewriting it in flex. My "html2wikipedia" is written in flex - it's really fast and didn't take long to write. The real problem is, I suspect that isn't the bottleneck.
It isn't. And there's no reason to expect flex to be any faster than any other language.
- You could start sending out text ASAP, instead of batching it.
Many browsers start displaying text as it's available, so to users it might _feel_ faster. Also, holding text in-memory may create memory pressure that forces more useful stuff out of memory.
Not an issue. HTML is sent out immediately after it's rendered. Things like database updates are deferred until after sending; the only time taken before that is spent in rendering, and as I said, that's not a bottleneck.
One things that would be nice is if the HTTP connection could be dropped immediately after sending and before those database updates. That's easy to do with threads in Java Servlets, but I haven't found any way to do it with Apache/PHP.