Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Experiment with Qt HTTP caching options #1012

Open
wants to merge 6 commits into
base: master
Choose a base branch
from

Conversation

HifiExperiments
Copy link
Collaborator

@HifiExperiments HifiExperiments commented Feb 9, 2021

potentially closes #92 and #990
fixes #1062

should theoretically

  1. remove the need for cachebusting
  2. improve loading times

also adds a reload button next to model URL in create

Test plan/open questions:

  • confirm that cachebusting scripts/models is no longer necessary (links won't update automatically, you'll still need to refresh the script or modelURL).
  • verify that the reload button next to model URL in create works
  • compare loading times (initial/loading from cache) between this PR and master. is this PR faster?
  • does it respect HTTP expiry times? can someone smarter than me make a test for this

@HifiExperiments HifiExperiments added enhancement New feature or request needs testing (QA) The PR is ready for testing needs CR (code review) labels Feb 9, 2021
@HifiExperiments HifiExperiments linked an issue Feb 9, 2021 that may be closed by this pull request
@digisomni digisomni added this to the 2021.1.1 Release milestone Feb 9, 2021
@@ -57,34 +55,6 @@ AssetClient::AssetClient() {
this, &AssetClient::handleNodeClientConnectionReset);
}

void AssetClient::initCaching() {
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

more info below, but for some reason, it seems like we were only setting up caching for this AssetClient, not for all other requests? this code moved to NetworkAccessManager::getInstance()

@@ -58,7 +58,7 @@ void HTTPResourceRequest::doSend() {
networkRequest.setHeader(QNetworkRequest::UserAgentHeader, NetworkingConstants::VIRCADIA_USER_AGENT);

if (_cacheEnabled) {
networkRequest.setAttribute(QNetworkRequest::CacheLoadControlAttribute, QNetworkRequest::PreferCache);
networkRequest.setAttribute(QNetworkRequest::CacheLoadControlAttribute, QNetworkRequest::PreferNetwork);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this should theoretically fix the cachebusting issue, see the docs for more info: https://doc.qt.io/qt-5/qnetworkrequest.html#CacheLoadControl-enum

QNetworkDiskCache* cache = new QNetworkDiskCache();
cache->setMaximumCacheSize(MAXIMUM_CACHE_SIZE);
cache->setCacheDirectory(cacheDir);
networkAccessManager->setCache(cache);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

according to the docs: https://doc.qt.io/qt-5/qnetworkaccessmanager.html#setCache

"QNetworkAccessManager by default does not have a set cache."

so...I think we were forcing PreferCache above, but then...not actually setting up a cache? hopefully this new code is more correct and more performant

@JulianGro
Copy link
Contributor

So originally when we discussed cachebusting the idea was turned down because of concerns about web servers being set up properly to support that feature.
While I was always for cachebusting, has the discussion happened again and the result changed this time?

@digisomni
Copy link
Member

This is implementing I think exactly what we were talking about. Webservers do have cache information in them, but currently we do not respect that. This gets us a bit closer to respecting that where possible.

@HifiExperiments
Copy link
Collaborator Author

yeah I think this is a pretty standard feature? this PR basically amounts to “use more default Qt values, and use them more correctly”

@Aitolda
Copy link
Collaborator

Aitolda commented Feb 24, 2021

Seems to work. A refresh button would definitely be useful. I uploaded a model,then modified is slightly in blender, reuploaded to my S3, then removed the link and repasted and the model. The updated model appeared without cache-busting.

@digisomni
Copy link
Member

One way to do this would be to have the refresh button empty the field and then paste back in the URL quickly (hacky method). The other method might be to have an actual scripting API call that allows you to just trigger a reload for a resource. Given that the system handles that pretty well...

It's possible that multiple parts of the system are looking at the URL for a change, but I'm hoping that it's simply the case that the resource being refeteched would update all layers. As for falling out of sync with others, it can send a message for others' Create app's to do the same call on that model?

@HifiExperiments
Copy link
Collaborator Author

yeah for now the best way to do this would be to set the URL to "" and then set it back to the actual URL, just to make sure everything picks up on the change. we might just need to copy how it works for the script field? someone who understands create more than me might need to take that over

@JulianGro
Copy link
Contributor

Theoretically you could lose the URL if the reload button removes the URL and adds it back. On Linux this happens often enough.

@ctrlaltdavid
Copy link
Collaborator

Note: In the Create app, the client script and server entity script fields both have a "reload" button.

@digisomni digisomni removed the needs testing (QA) The PR is ready for testing label Mar 11, 2021
@HifiExperiments
Copy link
Collaborator Author

ok added a reload button, ready for testing

@HifiExperiments HifiExperiments added needs testing (QA) The PR is ready for testing scripting api change Change is made in the scripting API labels Mar 21, 2021
@Aitolda
Copy link
Collaborator

Aitolda commented Mar 21, 2021

Refresh seems to work, but its worth noting the the new object will retain the dimensions or the original (reset dimensions will correct this). This is not a bug, and is desirable in many cases, but worth considering in the future.

@digisomni
Copy link
Member

Compared loading The Hub content on this PR versus 2021.1.0. There doesn't seem to be any noticeable difference for me,

Is there any way to make downloads work even if links redirect? I'm not sure how the system works or how things like that work in general.

However, between caching improvements and redirecting users to downloads that are on edge servers I think we can get fast loading times.

@JulianGro
Copy link
Contributor

Compared loading The Hub content on this PR versus 2021.1.0. There doesn't seem to be any noticeable difference for me,

My understanding is that, load times should be same or worse. Old behaviour is to just never update the cache. So whatever you downloaded would not change even if the source file changed. My understanding is that this PR contacts the server to find out if the cache is outdated.

@digisomni digisomni added rebuild rebuild through the GithubActions and removed rebuild rebuild through the GithubActions labels Apr 1, 2021
@digisomni
Copy link
Member

Test with webserver caching options set to no cache...

@digisomni
Copy link
Member

digisomni commented Apr 29, 2021

So, I've found that the refresh button doesn't update for file:/// or https:// cases, did not try others but basically I see the model blink as if it's reloading except the new model doesn't show up.

I test this by...

  • renaming my model on the server after loading it once
  • hitting refresh in the Create app, but the model stays the same it was even though it should be a whole new model, just with the exact same filename and path

However, the test for cachebusting in general worked successfully...

  • rename the model on the server after loading it once
  • go to the tutorial world under "Help" -> "Tutorial" then return back to the world
  • notice that the model is now the new model

I do not believe my caching options on the webserver affected either case much.

@HifiExperiments
Copy link
Collaborator Author

hmmm how is that different than what @Aitolda tried originally and reported success for?

@Aitolda
Copy link
Collaborator

Aitolda commented May 15, 2021

So I finally got to digging into this again and now I'm simply confused. I tried the newest version of this PR and couldn't get it working, so I started backtracking all the way to the first release on Feb 9, which was on the old protocol and it worked suddenly. Got excited, tried again, and it didn't work. Frustrated, I tried again and this time it worked. Seems to be inconsistent.

Here's what I've been doing.

I have two models that are both simply named "cube.glb" One of these is rotated off axis.
I load up one, confirm it's working. Go to the model box in the properties dialogue and remove the link or add some gibberish.
SOMETIMES the box becomes a green outline as expected. sometimes there is no effect on screen and the model remains.

Next I replace the original file on my S3 with the alternate cube.glb.
In the properties dialogue I re-paste the link (identical). If the model had turned into the green outline previously, I now see the new model as expected, but if it remained visible, nothing happens.

Again so far I've only got this working on the original Feb 9th version but it's worth trying the others again. Will keep investigating.

@daleglass
Copy link
Contributor

Going by Aitolda's comments it seems this needs more testing still

@digisomni digisomni added the dormant This PR is on hold but has interest/use surrounding it. label Nov 6, 2021
@digisomni digisomni added do not merge do not merge due to issues or pending updates and removed needs testing (QA) The PR is ready for testing labels Dec 18, 2021
@stale
Copy link

stale bot commented Jun 18, 2022

Hello! Is this still an issue?

@stale stale bot added the stale Issue / PR has not had activity label Jun 18, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CR Approved At least one code reviewer has approved the PR. do not merge do not merge due to issues or pending updates dormant This PR is on hold but has interest/use surrounding it. enhancement New feature or request rebuild rebuild through the GithubActions scripting api change Change is made in the scripting API stale Issue / PR has not had activity
Projects
None yet
7 participants