Creating organisations in GroupShare - best practice?

GroupShare performance, in terms of loading server data for example, appears to be currently quite poor (GroupShare 2017 CU4). I know SDL is currently (Nov. 2017) working to release some improvements which will hopefully address this issue.

Regardless of those expected improvements, is there any best practice in terms of organising the data that users could put in place to minimise impact to performance?

For example:

- Is it better to create fewer organisations with more memories in each or more organisations with fewer memories?

- Is it better to create one container per organisation or group several organisations to use the same container?

- Is it better to create fewer memories (one source - many targets) or more memories (single source and target memories)?

I'm sure there are other areas of data organisation that could be considered. Suggestions welcome.

 

 

 

Parents
  • Hi we have Groupshare with performance issues.
    We have a lot of Organisation and for every organisation i have Container with TM's we have TMS with multiple languages. But when they hit more than 750K TUs they are slow. (if you are importing something into this TM's it will took you at least 30 minutes or more.
    something that we found in studio if using multiple TMS and multiple Multiterm databases. Performance of studio is also very slow.

    So it is on you if you know how your projects settings are.
    But i found a best performance
    ORGANISATION TO CONTAINER 1 TO 1 AND HAVE MINIMAL NUMBER OF TM'S AND ALSO NOT TO BIG. IF YOU HAVE TM's with over 1M TUs your automatic task will be slow, translation will be normal when using Look-ahead (but here are also some issues). (project needs to be than crated into this Organisation or orphan organisation) (permissions on organisation than is complicated if a projects uses sources over more than One OU)

    i have so.
    OU level 1 here stored TM's, MT's and conatinaers
    OU level 2 (orphan) for projects
    users are not on root but they need some Minimal rights there so that they can view Organisation and also TMS.




    I'm on GS 2017 since CU 3 for production.
    Hopfuly this can help you.
    regards mitja
Reply
  • Hi we have Groupshare with performance issues.
    We have a lot of Organisation and for every organisation i have Container with TM's we have TMS with multiple languages. But when they hit more than 750K TUs they are slow. (if you are importing something into this TM's it will took you at least 30 minutes or more.
    something that we found in studio if using multiple TMS and multiple Multiterm databases. Performance of studio is also very slow.

    So it is on you if you know how your projects settings are.
    But i found a best performance
    ORGANISATION TO CONTAINER 1 TO 1 AND HAVE MINIMAL NUMBER OF TM'S AND ALSO NOT TO BIG. IF YOU HAVE TM's with over 1M TUs your automatic task will be slow, translation will be normal when using Look-ahead (but here are also some issues). (project needs to be than crated into this Organisation or orphan organisation) (permissions on organisation than is complicated if a projects uses sources over more than One OU)

    i have so.
    OU level 1 here stored TM's, MT's and conatinaers
    OU level 2 (orphan) for projects
    users are not on root but they need some Minimal rights there so that they can view Organisation and also TMS.




    I'm on GS 2017 since CU 3 for production.
    Hopfuly this can help you.
    regards mitja
Children
No Data