Answers.Body: <p>Do you have a few smart groups on which many others depend? If so it's worth making sure they're as quick as possible. We have a script that generates the important ones once per hour - but by putting the contacts into regular groups, rather than smart groups. Regular groups are much faster, and that speeds things up a bit.</p>
  
  <p>We've also turned <em>off</em> smart group caching. This very much depends on your use-case. But if you have a lot of intermittently-used smart groups it can be better to generate each one as needed rather than have a cron job regularly slow everything down by generating them all. But obviously ymmv on this.</p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-07T14:47:19.840Z
Answers.Text: We have a mixture of a few smart groups that others regularly depend on and quite a few smart groups that are infrequently run.  Is there a way to set up a cron job that only updates certain smart groups (smart groups that populate our website) but does not update other smart groups?
  
  Also, we do have smart group caching set at the standard 5 minutes.
  
  Is performance impacted by nesting smart groups inside of static groups?
Answers.UserDisplayName: J. Rolfs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-09T10:27:36.643Z
Answers.Text: I can't see a way to limit the cron to specific smart groups. But this doesn't seem like it'd too difficult to add. You could put it into the Paid Issue Queue.
  
  I would say performance is probably more related to the complexity of the critieria used for the smart group(s) - and how many levels of nesting there are.
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-10T04:32:21.117Z
Answers.Text: You can refresh a specific group with the contact api - try in the api explorer  - you need to pass the group param to the contact.get api
Answers.UserDisplayName: user4278
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-10T05:24:53.030Z
Answers.Text: Regarding the cron job to pre-build groups - usually it's a bad idea to run it. Any group that you try to render will be built at that point if not already cached & usually rendering a single group is not too bad (but often one bad group can cause chaos - trying to ping them in turn via contact api can help you find the one making your life miserable)
Answers.UserDisplayName: user4278
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-10T13:42:10.473Z
Answers.Text: This is all good information.  I'll look into implementing it.  I'm currently looking at the list of saved searches and there seems to be quite a few hidden smart groups.  Will performance improve if I delete those hidden smart groups or is Civi smart enough to know to not run those searches?
Answers.UserDisplayName: J. Rolfs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-11T20:57:10.500Z
Answers.Text: I think hidden smart groups are created when you send a mailing from search results. They're only used that once, so shouldn't affect performance elsewhere.
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-12T19:42:20.640Z
Answers.Text: Yes, Hidden groups are created when you send a mailing from search results.  I was looking at the sql tables and noticed that the hidden groups (both static and smart) are saved in the civicrm_group table.  A corresponding saved search also appears in the civicrm_saved_search table for smart groups.  Do the saved searches get rerun every time Civi updates the smart group cache or at any other time in background processes?  If so, I'll delete these groups and saved searches since we no longer need them.
Answers.UserDisplayName: J. Rolfs
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-13T10:26:26.493Z
Answers.Text: Afaik they aren't generated or touched ever again. I assume they're useful for mailing reports, though.
Answers.UserDisplayName: Andrew West
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-07T10:47:06.813Z
Answers.LastActivityDate: 2018-04-07T10:47:06.813Z
Answers.UserDisplayName: Andrew West
Answers.Body: <p>Have you used Smart Group caches?
  <a href="https://docs.civicrm.org/user/en/latest/organising-your-data/smart-groups/#smart-group-caching" rel="nofollow noreferrer">https://docs.civicrm.org/user/en/latest/organising-your-data/smart-groups/#smart-group-caching</a></p>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-07T09:03:19.267Z
Answers.LastActivityDate: 2018-04-07T09:03:19.267Z
Answers.UserDisplayName: Jon-man
Body: <p>After doing some research (<a href="https://civicrm.stackexchange.com/questions/18668/capacity-planning/18694#18694">Capacity Planning)</a>, it appears as if Civi slows down when there are a lot of smart groups or if the smart groups are children of other groups.  What should be some good practices to put in place so that the performance/speed of Civi isn't dramatically impacted by a large number of smart groups?  Thanks.</p>
  
Tags: <smartgroups><performance>
Title: Preventing slow performance with smart groups
ThreadText: # Preventing slow performance with smart groups
  
  (Asked by: username_0 on 2018-04-06)
  
  After doing some research ([Capacity Planning)](https://civicrm.stackexchange.com/questions/18668/capacity-planning/18694#18694), it appears as if Civi slows down when there are a lot of smart groups or if the smart groups are children of other groups. What should be some good practices to put in place so that the performance/speed of Civi isn't dramatically impacted by a large number of smart groups? Thanks.
  
  **Tags:** smartgroups, performance
  
  
  ---
  
  ## 2 answers
  
  ### Answer by username_1 on 2018-04-07. Score: 3 | Accepted answer
  
  Do you have a few smart groups on which many others depend? If so it's worth making sure they're as quick as possible. We have a script that generates the important ones once per hour - but by putting the contacts into regular groups, rather than smart groups. Regular groups are much faster, and that speeds things up a bit.
  
  We've also turned *off* smart group caching. This very much depends on your use-case. But if you have a lot of intermittently-used smart groups it can be better to generate each one as needed rather than have a cron job regularly slow everything down by generating them all. But obviously ymmv on this.
  
  > **Comments:**
  > **username_0**: We have a mixture of a few smart groups that others regularly depend on and quite a few smart groups that are infrequently run.  Is there a way to set up a cron job that only updates certain smart groups (smart groups that populate our website) but does not update other smart groups?  Also, we do have smart group caching set at the standard 5 minutes.  Is performance impacted by nesting smart groups inside of static groups?  
  > **username_1**: I can't see a way to limit the cron to specific smart groups. But this doesn't seem like it'd too difficult to add. You could put it into the Paid Issue Queue.  I would say performance is probably more related to the complexity of the critieria used for the smart group(s) - and how many levels of nesting there are.  
  > **username_2**: You can refresh a specific group with the contact api - try in the api explorer  - you need to pass the group param to the contact.get api  
  > **username_2**: Regarding the cron job to pre-build groups - usually it's a bad idea to run it. Any group that you try to render will be built at that point if not already cached & usually rendering a single group is not too bad (but often one bad group can cause chaos - trying to ping them in turn via contact api can help you find the one making your life miserable)  
  > **username_0**: This is all good information.  I'll look into implementing it.  I'm currently looking at the list of saved searches and there seems to be quite a few hidden smart groups.  Will performance improve if I delete those hidden smart groups or is Civi smart enough to know to not run those searches?  
  > **username_1**: I think hidden smart groups are created when you send a mailing from search results. They're only used that once, so shouldn't affect performance elsewhere.  
  > **username_0**: Yes, Hidden groups are created when you send a mailing from search results.  I was looking at the sql tables and noticed that the hidden groups (both static and smart) are saved in the civicrm_group table.  A corresponding saved search also appears in the civicrm_saved_search table for smart groups.  Do the saved searches get rerun every time Civi updates the smart group cache or at any other time in background processes?  If so, I'll delete these groups and saved searches since we no longer need them.  
  > **username_1**: Afaik they aren't generated or touched ever again. I assume they're useful for mailing reports, though.  
  
  ---
  
  ### Answer by username_3 on 2018-04-07. Score: 1
  
  Have you used Smart Group caches?
  <https://docs.civicrm.org/user/en/latest/organising-your-data/smart-groups/#smart-group-caching>
  
  
  ---
  
  