-
Notifications
You must be signed in to change notification settings - Fork 445
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
Comments
Also #1510 |
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. |
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 @simonkp @chiebert What would you think of a config setting for "Image Load Threshold" It would work like this:
|
@crossan007 I think that is a good idea. How will it work where pagination is available? |
please try now with 2.6.0 RC1 |
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. |
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. |
@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. |
@crossan007 does not seem to have changed anything :( I closed all browser windows and started a fresh session. no luck |
@crossan007 any other ideas |
Clear cache - old js file may have been cached client side |
That fixed it!!! |
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. |
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.
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.
The text was updated successfully, but these errors were encountered: