Dear folks,

I am working on a Drupal project that will heavily rely on biblio, therefore I'm watching the development carefully and play around with things as there are new releases. The 7.x-1.x-dev (25. May) was working really well on my sharedserver testmachine, so I populated it with 3749 randomly picked citations. The effect was: the whole site was still fast (especially after installing boost), but the biblio module took a serious performance hit with loading times of >5sec. This situation didn't change with boost, so I assume there is no caching for biblio pages ... But .. wouldn't that be a good thing to have, as some of us folks are quite eager bibliographs?

Keep up the good work, biblio really rocks!

Comments

Thorsten’s picture

Thorsten commented

Could it be that this caching issue is back with D7? http://drupal.org/node/724178
I'm not entirely sure when this happened, but maybe since an update of biblio caching for anonymous users seems weird. Anon uid=0, but with auth users (~0.65sec) the biblio list page is more than twice as fast than for anon users (~1.6sec.).
This happened for the third time now on my dev machines (D7dev/bibliodev/modules:BlockCacheAlter/EntityCache/HeadJS), can anyone reproduce?

Thorsten’s picture

Thorsten commented
Category: feature » bug
Thorsten’s picture

Thorsten commented
Title: Biblio pages seem not to be cached » Biblio list page seems not to be cached to anonymous users (under certain cond's)
rjerome’s picture

rjerome commented

Could you try commenting out line 146 in biblio.module and see what happens...


function biblio_init() {
  global $user, $conf;
  drupal_add_css(drupal_get_path('module', 'biblio') . '/biblio.css');

  if ($user->uid === 0) { // Prevent caching of biblio pages for anonymous users so session variables work and thus filering works
    $base = variable_get('biblio_base', 'biblio');
    if (drupal_match_path($_GET['q'], "$base\n$base/*"))
 //     $conf['cache'] = FALSE;            <------------------------LINE 146
  }
}
Thorsten’s picture

Thorsten commented

Unfortunately, it doesn't seem to be this ol'e bugger again ... commenting out 145/146 doesn't seem to change anything. Neither did commenting out 143-146.

rjerome’s picture

rjerome commented

To the best of my knowledge, that's the only place in the code where caching is touched so I don't have any easy answers to this. I'll do some benchmarking of my own and see if I can replicate the problem.

Ron.

Thorsten’s picture

Thorsten commented

I'll do a sound re-install for now, in the past that fixed the issue.
But at some point it kept returning, mostly after updates.
Let's see ...

rjerome’s picture

rjerome commented

Just out of curiosity, do you have any thing else on the page (blocks, etc) that might be loading differently for anon users?

Thorsten’s picture

Thorsten commented

Good question, no, it's just a login block that's loaded on this page and a "new members-Block" in the footer.
At the moment, I'm looking at possible interactions between other modules (views, date, calendar,block cache alter,headjs,entity cache) and greater numbers of entries in biblio (>2000), but on my fresh installation everything seems normal so far.

I'll send you a link to have a look at the phenomenon. I just noticed something new, the performance drop apparently applies to all user roles other than admins, so I should have a look at user privileges, too ...

Thorsten’s picture

Thorsten commented
Status: Closed (fixed) » Active

User provileges did the trick ...
My probably whacky idea of granting anon/auth users "Show own download links" privilege while switching "Show download links" off was what confused biblio. The time delay was produced by the generation of suppressed error messages.
Switching both off/on "Show own download links" AND "Show download links"made everything behave normally at the desired pace! :-)

Sorry for filing a bug report when misconfiguring - but hopefully this prevents others from running into the same issue. :-)

Thorsten’s picture

Thorsten commented
Status: Active » Closed (fixed)
rjerome’s picture

rjerome commented
Status: Active » Fixed

Actually, there was a bug in the code in the biblio_access function, since I was trying to access the $user object but it was never being passed to the function.

So the bottom line is that this issue really was more of a bug than misconfiguration.

http://drupalcode.org/project/biblio.git/commit/45d9c79

Ron.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.