• State Suggested Answer
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 48 subscribers
  • Views 2010 views
  • Users 0 members are here
Options
Related

Creating organisations in GroupShare - best practice?

Vicente Forcada

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.

 

 

 
Rate translation
×
Suggest better translation
×
  • 0
    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
  • 0
    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
  • 0 in reply to Frantisek Spicak
    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