Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I have block caching enabled, and here's why my cache_block table looks like: http://i.imgur.com/sBBer.png
I'm a little confused here... is there a reason that the apachesolr sort block has created so many entries?
Comment | File | Size | Author |
---|---|---|---|
#27 | 1814080-27-D6.patch | 757 bytes | pwolanin |
#25 | 1814080-23-D6.patch | 600 bytes | pwolanin |
#22 | 1814080-22.patch | 2.36 KB | pwolanin |
#11 | 1814080-11.patch | 2.4 KB | JordanMagnuson |
#8 | 1814080-8.patch | 2.4 KB | Nick_vh |
Comments
Comment #1
Nick_vhbecause the setting is :
Do you have the sort block on every page perhaps?
Comment #2
JordanMagnuson CreditAttribution: JordanMagnuson commentedAh... okay, thanks. That makes sense. I assume DRUPAL_CACHE_PER_PAGE does not count pager pages (i.e. ?page=3)?
Comment #3
Nick_vhThat is a good question, could you get back to us if you think this setting should change based on that research?
Comment #4
JordanMagnuson CreditAttribution: JordanMagnuson commentedYeah, I'll post back here if I find anything...
Comment #5
JordanMagnuson CreditAttribution: JordanMagnuson commentedYikes, looks like DRUPAL_CACHE_PER_PAGE does indeed cache the block for every single unique query.
So not only will this cache the block 100 times for 100 pager pages, but will apparently cache the block again for every single unique query/filter/pager combination.
So in my database, for instance, we get an entry in cache_block for:
apachesolr_search:sort:pixel_minimal:http://www.pixelscrapper.com/browse/assets?page=4&solrsort=ds_created%20asc&tid=&tid_1=cambodia&sort_by=created&sort_order=DESC&%24Version=1&%24Path=/
Since there are essentially an infinite number of possible combinations of pages, searches, and filters, the apachesolr sort block has the potential to create an infinite number of entries in the cache_block table.
What we need here is a version of DRUPAL_CACHE_PER_PAGE that ignores the query string, and just caches one version of the block for mysite.com/search[?ignores everything after] or mysite.com/browse/assets[?ignores everything after]. Maybe it would be possible to do this via custom caching?
In any case, I think the caching on the sort block can currently be qualified as a bug, because of how it fills the database without stopping. Much better to simply disable caching altogether on the sort block, until a better caching method can be implemented.
Comment #6
Nick_vhif you cache the block without the query string, you will get bad cache gets. Say you clicked on a sort link, it goes to the same page and it will return the cached entry. So your expected sort block will never show. As far as I can see we should sort on the path and the sort query parameter in the query.
Comment #7
Nick_vhhttp://realize.be/block-caching-pagers
We should implement something like this then. Care to take a crack at?
Comment #8
Nick_vhFirst attempt, works as expected here for my local testing. Can you confirm?
Comment #9
JordanMagnuson CreditAttribution: JordanMagnuson commentedThanks Nick! I would have been happy to take a crack at this, but you were pretty darn fast there!
Using this on production, and it seems to be working wonderfully! Nice work!
The only tiny change I would make is using the DRUPAL_CACHE_CUSTOM bitmask instead of DRUPAL_NO_CACHE, as it's a bit more accurate in this case.
Comment #10
Nick_vhThen I'm happy to see a patch with that change ;-)
Comment #11
JordanMagnuson CreditAttribution: JordanMagnuson commentedDone.
Comment #12
Nick_vhCommitted to 7.x-1.x
Comment #13
ianthomas_ukComment #14
pwolanin CreditAttribution: pwolanin commentedshoudl be backported to 6.x-3.x first?
Comment #15
pwolanin CreditAttribution: pwolanin commentedIs this patch even right? Seems liek you should be using the Drupal path, not parsing the URI.
Comment #16
pwolanin CreditAttribution: pwolanin commentedoh, hmm - I guess you want to include any search terms in the path?
Comment #17
pwolanin CreditAttribution: pwolanin commentedSo, 6.x-3.x has the default - which is I guess per role?
I'm not sure we should be caching these at all - that that faster than just rendering them?
Comment #18
JordanMagnuson CreditAttribution: JordanMagnuson commentedThat's a good question. It does raise the question, to have so many cache entries for such a simple block...
Comment #19
Nick_vhThe committed patch caches the sort block in any sort direction. This is most likely not more than 8 combinations.
If we can reduce any query to the solr server, I think we should. Think about someone that adds the sort block to the frontpage?
Where did the per user cache come from?
Comment #20
mkalkbrennersee #1970648: sort block breaks multilingual sites
Comment #21
pwolanin CreditAttribution: pwolanin commentedLet's stop caching here - this little block is not worth this hassle.
Comment #22
pwolanin CreditAttribution: pwolanin commentedreverts the commit above and sets the block to NO CACHE
Comment #23
Nick_vhDiscussed with pwolanin. Better to remove all caching as the theme function is literally two lines and it will help in simplicity
Comment #24
pwolanin CreditAttribution: pwolanin commentedpushed - needs backport
Comment #25
pwolanin CreditAttribution: pwolanin commentedD6 defaults to caching per role, which is not what we want
Comment #27
pwolanin CreditAttribution: pwolanin commenteddoh, careless editing.
Comment #28
pwolanin CreditAttribution: pwolanin commentedComment #29
Nick_vhClosing to clean the issue queue a bit