Attendance: mindless, bharat, pelle, valiant, Joe7, ckdake, beckett, h0bbel, rizzo, jozefs
Agenda
- Forum for 3rd party modules and themes
- Floating theme
- Openusability.org report and our reaction
- Review 2.1 Plan
- Template/Page level caching
- Session changes
- Bug fixes
- Other
Forum for 3rd party modules and themes
- agreed to add one in the g2 support category
- mindless: ok.. how about this: email -core with propose forum name, description, and new-topic template.. wait 1 day, then do it
- valiant: ok
- bharat: check how other projects deal with this
Floating theme
- Since thumb was very busy with the openusability.org report and the implementation of the recommended changes, he didn't really have time to work on the floating theme task
- The deadline for the task is still January 25th (for RC1)
- ckdake will work on the floating theme task and sync' with thumb
- thumb could help on theme related issues
- mindless: ckdake: so somewhere in the promote discussion part we'll decide whether to replace current matrix with this, or add a new theme along side
Openusability.org report and our reaction
- thumb is finished with the implementation of the suggested changes from the openusability.org report and the result is amazing
- maybe there will be some minor changes / fixes but the task is done
- bharat: we should get the next round of usability review
- valiant: yep, and we should write a GMC announcement and give her some feedback too
- further discussion to coordinate the GMC announcement, etc on -core
Review 2.1 Plan
- codename is set, still need logo.
- still targeting 25-Jan feature freeze, RC-1 soon after
- security audit scheduled for 10-Feb
- mindless: security audit will push us back a little, so we plan for RC-2 around 20-Feb or whenever we're ready after audit and 2.1 around 1-Mar
Template/Page level caching
- bharat: I started working on examining our queries but then I found a pretty good seam for template and page level caching
- bharat: so I've been working on that instead; I think that page level caching will give us a big umbrella to hide all of our performance issues under
- mindless: how does this work with dynamic content like random image block?
- bharat: ok so right now you can configure it like this
- bharat: you can choose template or page caching for users / guests
- bharat: ie, you can have a different policy for guests than you have for regular users
- bharat: and you can choose an expiration time for the cache (1 minute, 1 hour, 1 day, etc)
- bharat: so if you choose page level caching with an expiration time of 30 minutes then the entire page including the random image will be cached for 30 minutes
- mindless: is caching off one of the choices?
- bharat: mindless: yes
- bharat: if any user hits shift-reload on that page, they'll see a new random image and the cache will get updated
- bharat: if you choose template caching instead of page caching then all the {g->block}'s remain dynamic (because they happen at page render time)
- bharat: template caching caches the loadCommonTemplateData call
- bharat: that was the cleanest place to insert it that I could find
- bharat: to be honest, since that's only giving a 10% perf increase, I'm no longer sure that it's worth it. I guess it's better than nothing though
- Joe7: excuse me for interrupting you, but will this 'big umbrella' hide problems like the one with fetchDescendentCounts?
- bharat: Joe7: yes
- bharat: Joe7: for your site, if you enable page level caching your response times will go from 1000ms to 80ms
- valiant: but the nature of Joe7s site is that a lot changes continuously
- Joe7: yep..AND lot of users. so cache/user won't help it that much..or i might dont get it
- valiant: bharat: you've described the performance improvements from template/page level caching. what about cache misses / non-guest pages. how much slower do they get? when doing changes, how expensive is cache invalidation / rebuilding the cache?
- bharat: cache misses are pretty cheap; they're just one more very fast query
- valiant: what about invalidation / deleting the cache on viewabletree change events etc?
- bharat: I am factoring the ACLs into the key, but for registered users we have to track the userId as part of the cache because we may show the user name
- bharat: valiant: viewabletree changes don't need cache invalidation because they're permission related.
- bharat: I catch save/delete events and delete the cache for that itemId and its immediate parent
- mindless: "immediate parent".. classic theme has subalbum trees
- bharat: mindless: yup, some things will be slightly out of date because of this
- Joe7: why just immediate?..
- bharat: for performance.. if we start invalidating all parents, then we'll continually be invalidating the root page
- bharat: for busy sites that'll be counterproductive
- bharat: for site that have extremely popular front pages (lots of guests) with low penetration and a lower percentage of users this will be a huge improvement
- bharat: k. I'll have diffs for review shortly
- mindless: ok, thanks for the info bharat.. let's move any more discussion on this topic to after the mtg
Bug fixes
- mindless: i'm trying to find time to finish up password module.. still haven't gotten onto the bugfix rampage yet
- jozefs: Now that DP is not going into 2.1, I'd like to help with the release before continuing DP work. That is, if you have any tasks for me.
- jozefs will work on the release locks bug: http://sourceforge.net/tracker/index.php?func=detail&aid=1345508&group_id=7130&atid=107130
- There are still some high priority bugs that should be fixed for G2.1
Session changes
- valiant: as you know i'm moving persistent sessions from disk (files) to the db
- valiant: additionally, i'm removing persistent sessions for guests, unless they have important data in their session
- valiant: i've decided to not use a file based cache for the most recent sessions, reasons are in my status email
- valiant: to the second point: no sessions for guests, unless it's necessary. my conditions to give them a session are as follows:
- i ignore the permission cache that we store in the session (doesn't affect hidden albums, ...)
- i ignore the lastViewed data -> view counter increments more often. i use if-modified-since http header as an unreliable fallback for guests in the increment view count code
- i ignore the language, if the language in the session is the same as the one that we'd set for the request anyway
- and most importantly: i'm ignoring the navigation (navId)! that's hurting us, but i don't see a way around it
- valiant: but we gain a lot from that: no persistent sessions for guests, no session load db query for guests
- mindless: navigation links are mostly used for logged in users (using item admin / site admin)
- guests don't get a cookie and there's no sessionId in generated URLs for them
- bharat: that means we can back out the search engine detection code
- mindless: are there cases where we decide we need a session at some point during the request where we can no longer send a cookie?
- valiant: in immediate views and core.ProgressBar, when starting display(), you can no longer acquire a session
- should be done in a few days
Other
- Docs meeting is tomorrow, be there!
- rizzo is still mired in this contract job. but the end is in sight.
- beckett: mindless: still plugging away at theme docs... but haven't had huge swaths of time yet, so i'm inching along. i'd say with the docs finished up, we might be able to get the contest rolling right after the 2.1 release.
- h0bbel will write a GMC announcement/review of the linux toys book
