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

Performance limits exceeded on shared hosting when viewing large cart #1807

Closed
chiebert opened this issue Jan 27, 2017 · 15 comments
Closed

Performance limits exceeded on shared hosting when viewing large cart #1807

chiebert opened this issue Jan 27, 2017 · 15 comments
Assignees
Milestone

Comments

@chiebert
Copy link
Contributor

I've been testing/using ChurchCRM on a shared hosting account for the past few weeks, and have been getting periodic automated notifications from the provider to the effect that I've exceeded the built-in limitations on the number of processes (nPROC). When I've enquired from the hosting support queue, they've indicated that they've never run into problems with that limit before, but that it's all about multiple php threads or MySQL calls or calls to third-party APIs. But I've never been able to pin down what we've been doing that's triggering the high number of processes. Until just now: When I view a large cart (133 'members' in the cart, in my case), I hit the hosting limit - and about two-thirds of the way down the long list of members, the thumbnails are broken.

churchcrm__view_your_cart

I think I saw something way back in the closed issues about moving the thumbnail search to client-side API calls. I wonder if some sort of caching strategy might be in order, rather than hitting the API rapid-fire like this whenever we're building long lists like this?

The shared hosting I'm using has two higher-performance tiers, but highest one doesn't increase the nPROC limit by more than 50% over the current one. I'm sure others are going to hit problems with shared hosting as well.

@crossan007
Copy link
Contributor

you mean like #976 and maybe #1000

we could probably set a cache-age on the images so the browser uses local copy if present...

@crossan007
Copy link
Contributor

Also #1510

@simonkp
Copy link

simonkp commented Jan 29, 2017

Yes, I noticed that the cart view page is slower due to the image loading. To me images in cartview is an overkill. mostly used for data extraction, email, label printing etc for large number of records.
Why don't we remove the images from this page?

@DawoudIO
Copy link
Contributor

let us test after the new images PR and maybe do a PR to remove the images from cart if it is still an issue

@DawoudIO DawoudIO added this to the 2.6.0 milestone Jan 31, 2017
@crossan007
Copy link
Contributor

crossan007 commented Feb 5, 2017

@DawoudIO @simonkp @chiebert What would you think of a config setting for "Image Load Threshold"

It would work like this:

  • If the number of user thumbnail images on the page is greater than the threshold, then only initials are displayed.
  • If the number of user thumbnail images on the page is less than the threshold, then thumbnails are loaded from server.

@simonkp
Copy link

simonkp commented Feb 7, 2017

@crossan007 I think that is a good idea. How will it work where pagination is available?

@DawoudIO
Copy link
Contributor

please try now with 2.6.0 RC1

@chiebert
Copy link
Contributor Author

Sorry to be late to the game - I'm in the midst of a two-week vacation and just thought to check in. @crossan007 - your threshold idea sounds like it will work. Unfortunately I won't be able to test for another week and a half, as I don't have my laptop with me in paradise.

@DawoudIO DawoudIO modified the milestones: 2.7.0, 2.6.0 Feb 23, 2017
@DawoudIO DawoudIO modified the milestones: 2.8.0, 2.7.0 Apr 2, 2017
@DawoudIO DawoudIO modified the milestones: 2.9.0, 2.8.0 Jun 17, 2017
@rakess70
Copy link

rakess70 commented Sep 1, 2017

I am having the same issue. My host company said, Thanks for contacting Tech Support. I looked into the cause of your issue and it seems your scripts have been getting automatically killed by our Process Watcher script due to your sites going over the resource limits on the shared server.

@crossan007
Copy link
Contributor

@rakess70 please report here whether commenting this entire if statement: https://github.com/ChurchCRM/CRM/blob/master/src/skin/js/initial.js#L41 temporarily fixes the issue.

@rakess70
Copy link

rakess70 commented Sep 1, 2017

@crossan007 does not seem to have changed anything :( I closed all browser windows and started a fresh session. no luck

@rakess70
Copy link

rakess70 commented Sep 1, 2017

@crossan007 any other ideas

@crossan007
Copy link
Contributor

crossan007 commented Sep 1, 2017

Clear cache - old js file may have been cached client side

@rakess70
Copy link

rakess70 commented Sep 1, 2017

That fixed it!!!

@crossan007 crossan007 modified the milestones: 2.8.11, 2.9.0, On-Deck Sep 2, 2017
@chiebert
Copy link
Contributor Author

chiebert commented Sep 4, 2017

I confirm, temporarily commenting out that statement in initial.js and clearing caches allowed me to load up a large cart without getting the dreaded 'your account exceeded its resource limit' notice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants