Posted under General
albert said:
I'm experimenting with prefetching pages on post/index and priming the cache in order to reduce the per-page database overhead, although increasing the page rendering overhead.You can also now see how long each page took to generate and some system statistics.
Did this somehow cause the blank pages I get on mickey_mouse page 2, or touhou page 838 and above? I think the page selector is counting too many pages...
zatchii said:
Did this somehow cause the blank pages I get on mickey_mouse page 2, or touhou page 838 and above? I think the page selector is counting too many pages...
Seems like it's pre-fetching and skipping posts entirely for me. For example, I'll have a page end at *510, load the next page which starts at *509 and ends at *490. Hit back, click to load the page again, and it starts at *489 now.
The rel="next" meta-links on the pages are messed up too. On page 2, there are two rel="next" links, one to page 2 and one to page 3. On page 3, there are three rel="next" links, one to page 2, one to page 3 and one to page 4. I'd expect only one "next" link to the page that follows.
Opera uses these links for its automatic navigation (fast forward button or space bar to automatically go to the logically next page without having to click a link), and I've been relying on this. Now I keep having to click links to go to the next pages.
I've reverted the prefetching idea.
I've switched the tag query engine to use a GIN index which should make it much faster for multi-tag queries. This also changes the logic for OR queries slightly in that they now work in conjunction with AND and NOT tags.
The problem is still calculating related tags, which AFAIK can't be easily done using only a GIN index. This is why touhou+panties+monochrome still takes 3 seconds; it's trying to calculate the related tags every time. I'll investigate this later.
Oh, and you can no longer search for only NOT tags. I consider this a good thing because those sorts of queries basically require a sequential scan of the entire table.
Updated
You've seen this, I presume: http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/
LaC said:
You've seen this, I presume: http://antoniocangiano.com/2008/12/09/the-great-ruby-shootout-december-2008/
*blinks*
That manages to make LESS sense than the Power Analysis lecture I watched today.
*boggles*
Some minor fixes from Trac have been deployed.
Also for the curious you can check the Apache status here:
memento_mori said: Tag aliases are taking a while to apply now.
Also I got a timeout error posting this.
Emailed albert about this, it looks to me like the calculate_tag_subscriptions task takes a long time to run, and runs over and over, so it's really delaying everything else.
