Project

General

Profile

Actions
Copy link

Bug #28485

closed

Code that targets db's page table should use caching

Added by Raphaël Riel over 13 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Performance
Target version:
-
Start date:
2011-07-26
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
4.5
PHP Version:
5.3
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Many functions, including, but not limited to:
  • typolink() and it's variants
  • getPage() and variants
  • getRootline(), which could benefit SQL rewrite to avoid SELECTs in a while loop.

does repetitive, identical queries to DB's page table.
For my current project, within one page render, it's frequent to see the exact same query being issued to the database 3-12 times.

My biggest concern is when, for one page render, the total number of SELECT's sent for the page table exceed the number of row available in the table.

All the code using the page table would greatly benefit some caching.
Since pages are the central unit of Typo3, a central repository for retrieving ems could allow full caching of the table and save hundreds of calls to the database for a single page request.
It also could use the current caching backend to free up the database for content that's volatile from request-to-request.

Actions
Copy link
 #1

Updated by Steffen Gebert over 13 years ago

You don't think of fetching and holding all pages in memory, don't you?

Putting one page into a persistent cache only makes sense, if it's a memory cache. Therefore, we would need some additional layer between cache_runtime (PHP memory) and cache_hash (DB by default). Caching to DB makes no sense in this case ;)

I'm pretty sure that we will get such improvements for 4.7. Contributions are very welcome!

STeffen

Actions
Copy link
 #2

Updated by Wouter Wolters over 11 years ago

  • Status changed from New to Needs Feedback
Actions
Copy link
 #3

Updated by Philipp Gampe over 11 years ago

IMHO this is too generic ... there are several tickets that target individual caches.

Do we want to keep this is a master ticket (and move other tickets below this) or do we want close this?

Creating caches is not that easy as the code for typolink is rather complex and needs refactoring first (own class, smaller methods, unit tests) before we can thing of creating bigger changes.

Patches are always welcome, of course.

Actions
Copy link
 #4

Updated by Alexander Opitz almost 11 years ago

  • Status changed from Needs Feedback to New
  • Is Regression set to No
Actions
Copy link
 #5

Updated by Mathias Schreiber almost 10 years ago

  • Status changed from New to Closed

I'm closing this one.
We are working on an alternative tree scenario that will speed up the recursive method calls by.. well.. not working recursively anymore :)

Actions
Copy link

Also available in: Atom PDF