Project

General

Profile

Actions

Task #54121

closed

Speedup clickmenus using etags

Added by Stefan Neufeind almost 11 years ago. Updated almost 10 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Performance
Target version:
-
Start date:
2013-12-01
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

When fetching a context-menu (usually via AJAX) the returned document can easily sum up to a few kilobytes. The result is already set to "must-revalidate" so the client always gets an up-to-date result. Using Etags it's however possible to "hash" the returned data and if the client already has a previous copy with that exact same content return soon without having to send the data over the wire.

Actions #1

Updated by Gerrit Code Review almost 11 years ago

  • Status changed from New to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/25839

Actions #2

Updated by Gerrit Code Review almost 11 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/25839

Actions #3

Updated by Benni Mack about 10 years ago

Why not implement eTags for all BE requests?

Actions #4

Updated by Stefan Neufeind about 10 years ago

Yes, we could. I wondered if we should start small :-) But if you think of saving to re-transfer larger lists or so it might of course also save some bytes on the wire. (But the output would still need to be computed anyway.)

Helmut raised a voice in the review whether "saving bytes" is really worse the trouble of needing to think about potential caching-problems. He would like in-depth testing as well as speed-improvement-results. I'm not sure how to best continue here.

@Benny: But it's nice you like the idea :-) Your help would be very welcome.

Actions #5

Updated by Helmut Hummel almost 10 years ago

  • Status changed from Under Review to Needs Feedback

Stefan Neufeind wrote:

Helmut raised a voice in the review whether "saving bytes" is really worse the trouble of needing to think about potential caching-problems. He would like in-depth testing as well as speed-improvement-results. I'm not sure how to best continue here.

Well, implementing such a change without having a proof that it helps still does not seem reasonable to me.

Besides that, we should rather think about a good architecture to achieve our measurable goals rather than implementing a hack.
Caching and sending appropriate cache header for the backend is something we should evaluate in a broader scope.

A first step would be to implement a request/response model, which could then enable us to transparently add a HTTP caching layer (libraries are available for that already) between our response and the browser.

For now I tend to close this as won't fix and see where the entry point cleanup and module registration refactoring leads us to.

Actions #6

Updated by Christian Kuhn almost 10 years ago

  • Status changed from Needs Feedback to Closed

What Helmut says. This topic is much broader than just the clickmenu. The whole backend currently relies on 'not cached' and implementing eTags will easily introduce tons of issues in different scenarios. This needs a concept and not just an issue for some detail.

Actions

Also available in: Atom PDF