Looks like caching was never finished on the manifest. When the internet connection is slow this creates a very slow process of navigating the apps pages as it queries and downloads everything on each page refresh.

CommentFileSizeAuthor
#6 apps-manifest_caching-1403030.patch965 bytesTomDude48
#5 apps-manifest_caching-1403030.patch966 bytesTomDude48
#1 apps.caching.1403030.patch641 bytesrandallknutson
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

randallknutson’s picture

randallknutson CreditAttribution: randallknutson commented
Status: Active » Needs review
FileSize
apps.caching.1403030.patch641 bytes

Here is a patch that enables caching. This significantly speeds things up for me.

e2thex’s picture

e2thex CreditAttribution: e2thex commented

I think all we need to do is remove $manifest_cache = false;

e2thex’s picture

e2thex CreditAttribution: e2thex commented
Status: Needs review » Fixed

This has been address in http://drupalcode.org/project/apps.git/commit/13ef0ca

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

TomDude48’s picture

TomDude48 CreditAttribution: TomDude48 commented
Status: Closed (fixed) » Active
FileSize
apps-manifest_caching-1403030.patch966 bytes

I think the changes in #3 are different from the original issue. The manifests are still not caching. I have attached a patch to re enable manifest caching.

This greatly speeds up Apps page loading times and reduces the requests to the server.

TomDude48’s picture

TomDude48 CreditAttribution: TomDude48 commented
FileSize
apps-manifest_caching-1403030.patch965 bytes

Opps, sorry there was a bug. This one is correct.

febbraro’s picture

febbraro CreditAttribution: febbraro commented
Status: Active » Needs work 
+++ b/apps.manifest.incundefined
@@ -180,7 +179,7 @@ function apps_request_manifest($server) {
+      cache_set("apps_manifest_{$server['name']}", $manifest, 'cache', RESPONSE_TIME + 60 * 60 * 24);

Do we really want to cache for 24 hours?

TomDude48’s picture

TomDude48 CreditAttribution: TomDude48 commented

Where you thinking more or less? I thought that was a good balance but I am open to a different amount of time.

One concern is how slow the apps page loads are right now for the end user. Any amount of caching, even if it is just an hour will go a long way to solving that. (It has already made my testing significantly faster)

My concern longer term is how much stress it is putting on the Apps server. We currently have people hitting the server 100 times a day or more. There are a few times where the server has gotten overloaded. We are already looking at bumping up the instance size of that server to deal with the request we currently have. Hopefully in a few months it will be 100x that. ;-)

randallknutson’s picture

randallknutson CreditAttribution: randallknutson commented

Keep in mind that they can always clear cache to get a new manifest from the server so a longer cache time is not necessarily bad.

febbraro’s picture

febbraro CreditAttribution: febbraro commented

If I'm not mistaken, the cache clear (like drush cc all) would only clear things that are cached as temporary. The timestamp will keep it in the cache for at least that long, after which it becomes temporary.

febbraro’s picture

febbraro CreditAttribution: febbraro commented
Status: Needs work » Fixed

Thanks for pointing it out guys. I put caching in place, but for now left it at 1 hour TTL.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.