Block cache refresh value incorrect causes load problems
asb - December 26, 2007 - 20:15
| Project: | Block Cache |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
Hi,
I'm trying to enhance the user experience of my Drupal site by reducing page loading times; I was hoping that Block Cache would help with it.
However, the configured and cached Blocks significantly _increased_ the page loading times (from ~6 secs to ~40-60 secs).
Anonymous users see 6-8 blocks, logged in users up to 12; I spent hours configuring each block with sensible values. What could be going wrong here? Is there any documentation or "best practice" guides availabe?
Thanks -asb
#1
i can say the same.
I noticed that the block cache module didn't obey the settings i gave for the blocks and the cache was being refreshed every time i would do something on site. I turned off those settings, but the cache was being refreshed.
We had more load on server. However, in start i thought and felt that things were faster.
I guess some improvement is needed for the module.
Thanks
Dhaliwal
#2
Exactly the same behavior here... Very strange effect. I also thought at the beginning that things became faster, but when I finished configuring the blocks it dramatically increased page loading time...
Before:
Executed 282 queries in 3194.18 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 3689.21 ms.
After:
Executed 378 queries in 16084.06 milliseconds. Queries taking longer than 5 ms and queries executed more than once, are highlighted. Page execution time was 17073.93 ms.
...
Changed this issue to "bug report", "Critical", Component "Code".
#3
Hi,
I disabled the module and reconstructed the default blocks; now, the site is (more or less) fast as before.
The module is a nice idea, but in it's current state, I can't recommend it.
Regards, -asb
#4
Thanks you VERY MUCH for your review!
I´m monitoring the development of this module because the idea behing it is great.
Thanks!
Rosamunda
#5
To the people having this problem, can you state more specifically what your settings were? I don't experience this on any of my sites where I use block cache so I would say this is a configuration problem and not necessarily a module specific problem.
#6
Hi, I'm sorry. I tried it one again and everything works fine... Can't reproduce the error.
#7
#8
i have noticed that the module works fine.
Maybe we forget to change the cache timing. Each block cache refresh time should be set correctly for this module to increase performance.
I find it a good idea to optimize site speed.
#9
@jjeff and @greggles:
I think I found two more or less critical bugs which may produce this strange behavior:
1. Deactivated blocks are NOT ignored, which means that the settings for
are active for every block, even if it's not active. This produces a lot of unnecessary queries on sites with a lot of blocks. Using some special modules there can be hundreds of blocks (!!)...
2. what gdtechindia wrote is not right in every case, but there is a behavior like this on my site too.
I have two blocks with the following configuration which ignore the settings as far as I understand the module:
I expect these blocks to only refresh every 10800 sec. but they refresh on every interaction.
Is this just me, not understanding the config? Or is this a bug?
#10
#11
(also included in a post at http://drupal.org/node/258209#comment-860926)
in response to the last comment (#9), is there a way in the code of the module to turn this OFF by default for all those options? It seems like it could just be a hack to a module to set all defaults to FALSE instead of TRUE, but I don't know this code well enough
#12
I'm closing this issue. Discussion on the newer posts should continue in the new issue regarding that #258209: DELETE FROM cache_block locking issues..
#13
I think there is a bug in line 302 of blockcache.module, it should be:
$refresh = variable_get('bc_refresh_'. $r->my_delta, array($type => false));instead of:
$refresh = variable_get('bc_refresh_'. $r->my_delta, array($type => $type));This way, if nothing has been selected in "refresh when" option, the default value for 'bc_refresh_$delta' variable
will be false, and DELETE FROM..... will not be executed until the cache_lifetime value is reached.
#14
@unknownguy, thanks for your investigation. Do you have a simplified repeatable test case that would allow someone to see the incorrect behavior?
In short, how can we test this to say whether it's ready to be committed or not?
#15
He greggles,
I'm sorry, I don't have any test case. Currently I am not using the module, but we might use it in the future so I was reading the issue list and found this one.
Then I began to read the source code and found what seems obvious to me, but I must say that I have not test it, maybe someone else can do it, sorry.