Workings of Authcache

How authcache works is to cache pages on a per role(s) basis. (or rather based on the combination of roles a user has)

How Authcache Works
=============

For example "user1" visits a page with roles "A" and "B". No suitable page exists in the cache, so a page is generated and then stored in the cache with a cache prefix of "AB".

user2 visits the same page and has roles of "A", "B" and "C". The previously cached page is not valid for them since the "C" role is likely to change their view of the page, so a new page is generated and stored in the cache with a cache prefix of "ABC".

user3 visits the same page with a role of "A". Still no cached pages are valid so a new page is generated and cached with a cache prefix of "A".

user4 visits with roles of "A" and "B". Eureka, a cached page exists with the cache prefix "AB" so user4 gets a fast page.

It follows, that the more roles you have on your site (and/or) the more roles assigned to each user, the less likely you are to get cache hits.

Backend Storage
==========

Authcache uses whatever backend cache you have configured to store it's data. Commonly this is something like memcached or filecache or even the standard Drupal database.

If you're using memcached, it's conceivable with a very large site you may run out of RAM but for example, a thousand pages (assuming an average of say 50K of html per page) only uses 50Mb or so of RAM so you're probably going to be fine. I'm not that familiar with memcached, but I'm assuming it has the ability to de-cache things when it's allocated RAM is full so even if you had many thousands of pages and not much spare RAM, you would still get a very useful speed increase from authcache.

Personally, in most cases, I would use Filecache. It's about the same speed as memcached (because unix automatically caches frequently read files in RAM) and is only limited in storage by the size of your hard drive. I use a modified version of Filecache which is actually quite a bit faster than memcached - details of which I must get around to posting on the Filecache project page.

Generally, Authcache allows developers to add "personalised" elements to the page using javascript. Comments are one such example that is automatically handled by Authcache.

Facebook likes are already handled using javascript on the client so they are not affected by Authcache (ie FB likes should work exactly as before)

What I would *guess* would happen with Flag likes is that the user would "like" something, the Flag module would update the database would but the page would not appear to have been "liked" because the user would still see the exact same page generated by Authcache.

You might try the "Content Refresh" module (which may or may not help you) or this might be something that would require a custom module to make it work how you'd like.

>how can I know?

Do more thinking / reading about how caching works and the associated challenges / compromises (sorry if this isn't that helpful. I could probably write a book about caching / performance tuning, just not here and now!)

>Thanx simg, but shouldnt there be some documentation what authcache does and doesn't do?

Well, that depends on what you mean by "should" !

There is some documentation linked to from the Authcache home page but I can see that it isn't going to be that helpful if you're not already familiar with the issues and challenges surrounding caching - and even then it's somewhat difficult to digest and understand. Would it be better if there was more, better, easier to understand documentation? Of course, but who "should" write this documentation? I'm doing what I can but there are only so many hours in the day...

>Guessing that they made some extra code for commenting but they didn't for flag, but it is similar principle, DB is updated and needs to be refreshed, so why should only comment work and not flag?

Comments are core Drupal functionality so it makes sense that Authcache would handle comments. Flag is *similar* to comments as you suggest, but it's still a special case so far as programming a solution that would work.

>other than that they made custom code just for comments, or there should be custom code for all modules needed to refresh and this to be even some kind of API for other modules?

Things get tricky at this point. Should Authcache try to work out when to refresh the cache? How would it know? Just because a node gets updated that doesn't mean the cache should automatically get refreshed. Should there be an API for other modules? Maybe, that's an interesting idea, but that would mean that all other modules would need to be modified to work with Authcache (or maybe Authenticated caching should be handled in core)