Jazz Forum Welcome to the Jazz Community Forum Connect and collaborate with IBM Engineering experts and users

DNG 5.0.2 : Poor performance

Im working on a DNG 5.0.2. and I've a DNG Module with 10,000 artifacts (approx.) and it is going to be larger (up to 20000 artifacts) in addition to more diagrams. I'm working on a Chrome WEB browser as an interface to a far distance DNG-Server.

The performance is poor. The Manual refresh (F5/CTRL+F5) can takes a 40 seconds and the Copy-Paste of a section with 200 artifacts can takes even few minutes. Does it make sense ? Is it normal behavior? Is it recommended to split this single module to a few smaller modules in order to improve the editing?

Thanks in advanced. 
Yoram

1 vote


Accepted answer

Permanent link

Please the current limits for folders, modules and artifacts in https://jazz.net/wiki/bin/view/Deployment/DOORSToDNGMigrationSizingGuide . Those are for 6.0.x but I think that 5.0.x would have similar limitations.


I think that you are already at the limits and it would make sense to try to split.

Yoram Ben-Haim selected this answer as the correct answer

0 votes

Comments

 Thank You very much


One other answer

Permanent link

Hi Yoram,

As Ralph points out, even in 6.0.3 we do not recommend module sizes above 10k and in 5.0.2 it was the same.  If you create 20k artifact modules you have to appreciate that you're introducing a trade off sluggish fetch times for the users.  This needs to be strongly evaluated (larger queries hitting the server; more focus on one area of data etc) before you continue down that path.

The problem here though is likely to be your access times to the Jena indices.  So see the chart here for knowing where you are on the overall scale.  1 user and 1m artifacts is still going to need some decent hardware.
Also note that in 5.0.2 the indices were larger.  Up to a third in fact due to the comments, so where you indices reside is going to be hugely important.  SSD will make a night and day difference to your system.

A word of warning on manual refresh.  You are undoing all the caching and causing a refresh from the server, so once you know that you realise that this is an expensive operation and you probably want to avoid it.

If you look at a .har file output (or similar, Developer tools in Chrome) then you can see if the delay is network related or purely fetch times from the server.  The server itself is also going to report out in the rm.log if it is being overworked.
You might also encounter database delays, so check that for latency & ensure that server is not under strain...although the behaviour you describe is more likely indices.

Further than that you may need to open a PMR with the Support team to get to a root cause, but if you exceed 10k artifacts in a module...you know what we're going to say first!!

Finally, the Performance report for RDNG 502 should give you an indication of what timings to expect as normal for the hardware you have.

Kind regards,
Paul



0 votes

Comments

 Thank You very much Paul

Your answer

Register or log in to post your answer.

Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.

Search context
Follow this question

By Email: 

Once you sign in you will be able to subscribe for any updates here.

By RSS:

Answers
Answers and Comments
Question details
× 12,029

Question asked: Mar 14 '17, 6:52 a.m.

Question was seen: 1,752 times

Last updated: Mar 14 '17, 10:14 a.m.

Confirmation Cancel Confirm