The manage groups page does not force a refresh of the smart group cache but there is a button to do so on the right-hand side:
Without clicking that button, what it does do is count the number of contacts already in the cache, but this query has been optimized and tested against a very large (6 million group_contact records) database.
You'll find more ...
This one also throws me occasionally. You should reduce the dashboard cache timeout setting to '0' in /civicrm/admin/setting/misc?reset=1
Then it will load the reports dynamically each time you access the dashboard.
Pretty sure that we only consider active groups to regenerate the cache:
also most smart groups are regenerated on demand. The scheduled job invokes the loadAll function with groupsIDs as null, which in turn restricts the query to is_active groups
When looking through the list of cache drivers, you see options like Memcache, Memcached, and Redis. Generally there's little reason why a deployment would use all three -- rather, the typical question this:
Do we have any kind of high-speed/shared/memory-based cache? If so, use it.
Do we have any kind of SQL-backed cache? If ...
I found the corresponding reference page here:
Set a cache value with Civi::cache()->set('mykey', 'myvalue');
Get a cached value with Civi::cache()->get('mykey');
Delete a cached value with Civi::cache()->delete('mykey');
Flush the entire cache with Civi::cache()->flush();
Cache files are cleared by a scheduled job, which isn't enabled by default.
Go to Administer menu » System Settings » Scheduled Jobs.
Find the row labeled Clean-up Temporary Data and Files.
On that row, click more menu » Enable.
Our CiviCRM was installed outside of the Drupal root in order to circumvent performance issues with Drupal commons. I have re-engineered so that CiviCRM is now inside the Drupal root and upgraded. I also noticed multiple instances of Drupal in /var/www/html so I moved all other copies to a backups folder outside of the html folder.
We no longer have this ...
I had the same reaction when I saw that field -- it doesn't appear to be used.
In fact, I don't think it was ever used. Grepping some of the older releases (http://svn.civicrm.org/civicrm/branches/v2.0, http://svn.civicrm.org/civicrm/branches/v2.2), the field appears as part of the 2.1 schema upgrade; however, even then it's not used in any logic.
Ugh. This kind of bug is really hard to diagnose. Good call on noticing that memcache caches this behavior.
Are you on some kind of host with really aggressive caching by default? WPEngine, for example, has caused big problems.
If not, you should report this on issues.civicrm.org. My hunch is that caching/retrieval of the query for visiting the contact ...
Currently the function CRM_Core_Invoke::rebuildMenuAndCaches does not flush the memory caches, even though it will rebuild the database cache, menus and sessions. In order to also flush the memory caches you need to also call: CRM_Utils_System::flushCache( ); (This was confirmed by Lobo but I think it needed to be written more explicitly as an answer and not ...
You can manually clear caches with civicrm_api3('AnyEntity', 'getfields', array('cache_clear' => 1)); (use any valid entity, it doesn't matter which).
However, if you are using the api to create tags, and this does not automatically clear the cached list of tags, I would consider it a bug. If you are able to reproduce it in the latest version please look ...
Unfortunately, the log message suggests you've hit a limit of your hosting provider.
User snachodo_657 already has more than 'max_user_connections'
This could have various causes. If your hosting plan only allows a certain number of DB connections simultaneously and your site creates more than that, you'd see this.
I don't think it's a common issue for ...
I think the function CRM_Core_Invoke::rebuildMenuAndCaches should also flush the memory caches, and hence call: CRM_Utils_System::flushCache( );
This will make things more consistent and actually rebuild all caches as the function name suggests
A big part of the pages in civi are not public, so as you might serve different pages to every user, they can't be cached.
But I think your problem is elsewhere, if you are "alone" on your admin pages, it should not be slow, even without varnish
Have a look at the demo pages, are you experiencing the same speed on your server? if not, there is something ...
I am using the webhosting service of Rochen, and they use a LiteSpeed Web Server.
Civicrm runs inside a Joomla 3.7.5 website quit okay. (The the current Joomla version of 3.8.2 and Civicrm do not work together okay, because there are still several issues due to changes in the Joomla 3.8.* versions.)
So as to your main question: Litespeed can be setup to ...
civicrm_activity is a legitimate table with legitimate data. You can use the API to mass-delete activities - but only you (and/or your users) can determine what represents data that is reasonable to delete.
If it's that large, I suspect it's quite likely that you're sending frequent mailings to large groups of people - the mailing history might be ...
I'm happy to report that the original issue was resolved with an update to 5.5.1. With this update made, the errors illustrated in my original post are no longer occurring.
Because we've long used CiviCRM without this error and first noticed it with 4.7.31 (and consistently with subsequent upgrades), we believe that this new upgrade has returned the ...
You will find different ways of clearing cache (as Jon mentions) documented HERE, but I agree with Tony that perhaps the UI would be easier - maybe it's just a question of adding a top menu item on the navigation menu or a button that will trigger /civicrm/clearcache?
Hope this helps!
Expanding on Tamar's suggestion:
Go to Administer > Customize Data and Screens > Navigation Menu
Click Add Menu Item
Title: Clear Cache
Parent: leave as Top level, or configure as you like
Refresh the page and you should find a new entry in your menus to clear the cache.
There's something wrong with your smart group with an ID of 95. However, this is unlikely to be causing a performance problem, since this query simply isn't running. If you can delete and recreate your smart group with an ID of 95, this error should go away.
The only way we could solve this was turning off php opcache in fpm/apache/nginx and cli
For other sites with opcache turned off we had to enable schedule job 'Clean-up Temporary Data and Files' with parameters
Incase you have memcache enabled then
I had this experience with a Drupal 8 site and fixed it by enabling the permission "access custom fields" for anonymous visitors.
In our case, the issue was that anonymous visitors couldn't access the custom fields, so if the cache was cleared, it would get populated via the anonymous access rules and that same cache was used for everyone.