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,
    thank you for asking this question here! We are struggling massively with GS 2017 performance (the time until TMs are loaded is just not acceptable) and it is still showstopper for us to go ahead and deploy it productively. So as a test, i installed GS 2017 CU4 to new server pair, i did not create any organization, additional user or language resource. I only created roughly 2000 TMs (this is size of one of our productive servers) which reside directly in root organization.
    The loading time did not differ much from situation what we have on productive servers, where we have :
    - Org. Structure:
    /ROOT/TRANSLATION/<lng combination>/Departments(type of content)/TM's
    - Containers are devided per Department
    - Lng. resources and other items are linked from one single organization
    - Users (Vendors/Translators have access from the level <lng combination> further down
    - Even for those users the time is over 3 minutes until they see the content

    regards,
    Fana
  • Hi Fana, Are you also having perfomance issues with TM update batch tasks and analysis batch tasks, we are seeing examples of TM update batch tasks taking 50 x longer on a GS2017 server memory compared to the same memory created in an equivalent file based format. As you say this version of Groupshare doesn't appear to be fit for production deployment.
    emoji
Reply Children
No Data