Welcome to Telelogic Product Support
  Home Downloads Knowledgebase Case Tracking Licensing Help Telelogic Passport
Telelogic DOORS (steve huntington)
Decrease font size
Increase font size
Topic Title: Maximizing DOORS performance
Topic Summary:
Created On: 5-Jan-2009 22:05
Status: Post and Reply
Linear : Threading : Single : Branch
Search Topic Search Topic
Topic Tools Topic Tools
Quick Reply Quick Reply
Subscribe to this topic Subscribe to this topic
E-mail this topic to someone. E-mail this topic
Bookmark this topic Bookmark this topic
View similar topics View similar topics
View topic in raw text format. Print this topic.
 5-Jan-2009 22:05
User is offline View Users Profile Print this message


David Ofstead

Posts: 3
Joined: 9-Oct-2008

When implementing a DOORS database, what should be used or avoided in order to maximize speed/performance?

I am concerned about the use of Layout DXL, Attribute DXL may hurt performance.

Does the use of # includes in DXL hurt (assume data is quickly accessible, <10ms)

Should default views for modules avoid layout/attr dxl?

Triggers to avoid?

Do certain graphic types hurt?

Link module no-nos?

Access control no-nos?

Change History no-nos?

What else impacts performance?

Sorry this isn't a pure DXL question.. any tips appreciated.
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 00:45
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

Layouts, Attr-DXL, and Triggers initiate quickly. What matters is what that code does. That is, I'm claiming that a human being won't notice a Attr-DXL nor Trigger that does nothing.

Layouts fire each time the object in the module window is updated. I wrote a layout that printed 'hello' and put it in a module with 4 objects. Each time I selected a new object, the layout fired between 15 and 20 times. If I clicked and dragged some other Windows and moved it over the Module window, the Layout fired 100s of times. That is, a human being might very well notice a layout that does nothing.

Layouts should only be used when they are very simple. Layouts that perhaps traverse links and summarize the linked objects will result in hopelessly slow performance, since layouts are recalculated an order of magnitude more often then attr-dxl.

The main advantage of Layouts over Attr-DXL are they [1] don't require edit access to the module to create [2] won't confuse DXL that browses attrbutes and obj-attr values.

I've got some scripts that browse through the objects in a module, calculates some stuff, then sets some Attribute value with the result. Script 'FindCPs.dxl' manages attribute 'FindCPs'. Such scripts can be run on demand but are scheduled to run nightly. This approach is inferior to Attr-DXL since the update is generally a day behind, but it has the very significant advantage that I can update the script and don't have to modify a bunch of Module's Attr-DXL definitions.

Yes, try to avoid default views with layouts or attr-dxl.

As for triggers, Triggers fire quickly and the events that initiate the trigger are generally infrequent. Even a trigger that fires when you modify an object-attr combined with a DXL that modifies obj-attr values, will not affect performance (unless, of course, if the trigger code is very complicated). Triggers are rather dangerous, however. On a scale of 1 to 10, where 1 is creating a desk-top shortcut and 10 is letting a monkey edit the Registry, writing triggers is a 7 whereas writing normal DXL is about a 5. I've got some collegues who absolutely disallow any triggers in their database, with some reasonable justification.

#include statements in Triggers, Layouts, and AttrDXL are problematic unless you are SURE that all the clients have access to the computer housing the DXL, which is usually not the case. Even if you do, the module will generate lots of DXL errors if its archived and sent to a contractor's database. With an increase in complexity and a hit in performance, you can simulate an #include statement via use of 'readFile' and 'eval_', but passing the object in question to the eval_ code should be done via some sort of AbsNo function parameter. That is, the Layout tries to read the DXL file from the network, and if successful it passes the Absolute Number of the 'obj' and the read code to 'eval_' for execution.

Opting to save OLE diagrams in History will eventually affect module-load-time performance.

The main performance issue in DOORS is the network band-width between the Server and the Client; that is clients that are 'far away' from the server on the network have drastically worse performance than clients that are 'close' to the server. That's the main reason Citrix works so well, so long as the Citrix server(s) are close to the DOORS server: the amount of screen-shot data that goes from Citrix to client machine is an order of magnitude less than the underlying data that goes from the Server to the (Citris) DOORS client.

- Louie
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 17:58
User is offline View Users Profile Print this message


Thomas Young

Posts: 20
Joined: 12-Apr-2005

Another contributor to bad performance is when the # of linkset pairings (LSPs) get out of hand. LSPs are stored at the folder level. In a given folder, if the number of LSPs gets up in the hundreds, (which can happen when all possible permutations of linked module pairs are considered in a folder containing say, 30 formal modules), the act of creating a single link can take a over a minute. Running linking scripts that create links throughout a module (such as the Link by Attribute tool) can take an hour and a half.

For this reason we have limited, but not eliminated, the use of LSPs. We've also beefed up education to users who create links, encouraging the use of custom addins DXLs (which of course use specific link modules) to create links en masse, instead of manual linking. On those occasions when manual linking is the best option, we've provided a script that makes it easier to change the user's default link module. And don't forget the trick of having a soft-deleted "DOORS Links" link module in each folder, to prevent that bugaboo.

The LSP performance issue may be less common but is something we've had to deal with. Louie may have some comments on this too.

-TY
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 18:06
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Originally posted by: David Ofstead
Do certain graphic types hurt?
Link module no-nos?
Access control no-nos?
Change History no-nos?
What else impacts performance?
Sorry this isn't a pure DXL question.. any tips appreciated.


Louie already covered the other stuff pretty well but I'll add, generally for any useful layout dxl, try to avoid having layout DXL columns in a module default view. And for Layout or Attribute DXL, use Buffers instead of strings.

Graphics: Be careful when putting graphics in DOORS. It stores it as a string and as such, it goes into the string table. This means the string table can get quite large. And if you say take an image from a word document, first double check the actual size of the image. An image sized down in a word document may still be a 2560x1600 size image in reality. Putting that into your DOORS module will slow it down.

Links: Link modules should always be declared and link pairing should always be defined and not overidable. This is done in module properties. Define your link pairings!

Access: For attributes, standard users only need RM for the value and R for the definition. For modules, give them RC. Then propagate Modify and Delete since that will give them RMCD for objects. Propagate Admin access to objects if they need to be able to set objects for share, but still remember to go to each attribute and set the permissions otherwise they'll have RMCD or RMCDA for all the attributes.

History: Baseline every so often to clear history. How often depends on how many changes are made in a given time period. Also if you're going to be doing a lot of link creation and deletion, turn off saving link history in the module properties.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 19:17
User is offline View Users Profile Print this message


Louie Landale

Posts: 2070
Joined: 12-Sep-2002

We had some problems with LSPs in v6.1 and I wrote a script to clean them up. IIRC, and LSP becomes invisible in the GUI if either of the named modules no longer exists, such as when its moved or renamed. The script searched out these invisible LSPs (LMDs in DXL), those whose source or target no longer existed, and deleted them.

Since LSPs are strangely stored in the source's folder instead of in the source module (as are views), when you move or archive a module you lose all its LSPs; I hate it when that happens.

I don't have much recent actual experience with use of LSPs or even with creating links manually, since our partner's here have a policy of defining desired links in text attributes, and running a speciallized DXL that actually manages the links (a glorified link-by-attribute script). Nice to know that many LSPs will drastically slow down the GUI.

I wonder in DXL when you create a link specifying the Link Module Name, if its noticably faster than when you don't specify it.

- Louie
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 20:15
User is offline View Users Profile Print this message


David Jakad

Posts: 94
Joined: 20-Jul-2007

I just want to reiterate Louie's comments about the slow performance of clients that are 'far away'. It's been my experience that the large amounts of data that are exchanged between the server and the client, over relatively-slow remote connections, is the biggest source of performance problems, and overshadows any other performance issues.

For better or worse, I use DOORS as a 'far away' client. The database server is some 1500 miles away. It's bad in that performance can be slow. But, it's good in that, when I develop DXL, I am sensitive to this issue.

In general, every time you open a module, DOORS creates an entire cache copy of that module on to your local machine. This creates two performance issues: 1.) a lot of network bandwidth usage and 2.) a lot of RAM usage on your local machine. The problem gets worse the bigger the modules or the more modules you open.

After opening a few large modules, my Task Manager often shows DOORS eating up 700-800Mb of RAM. If you have insufficient RAM, your PC will start caching to the hard drive, bringing your machine to a crawl. I've found that 2GB of local RAM is a minimum.

Bandwidth is another issue, as individual modules can be quite large. When you open a module, DOORS creates its local copy on your machine, eating up network bandwidth in the process. DOORS can appear to freeze up, when its really just opening another module. Some advice here might be to keep modules to a certain size, and break them up into multiple modules when they get too big. Although, this is often out of your control.

As others have mentioned, it's good to avoid Layout DXL that opens a bunch of modules, or else the view will be very slow. One solution for Layout DXL is to include checks to see if the module you need is already open and/or to only open specific modules you need. Although this can still be slow, because these checks may get run 100s of times just by dragging another window over your module window, and the checks still require a request/response between the server/client each time.

One of my solutions for Layout DXL is to open all the necessary modules you might need for the view once, and write to a local system variable indicating this step has already been done. So, at the top of my Layout DXL, I may have something like:

string SessionSaved = getenv("DOORSsession")
string SessionNow = username ":" stringOf(dateAndTime(session)) // or any munged session-unique identifier
if (SessionSaved != SessionNow) {
// hard code to open all relevant modules here
setenv("DOORSsession",sessionNow)
}

A view with this Layout DXL will be extremely slow when first opened, as it opens all necessary modules up front. The view is relatively fast after that, since it will no longer open any modules, but simply checks a local system variable. Although, if a user subsequently closes one of the modules needed for the view, some of the information in the layout column will be lost.

Another option is to create DXL dialog boxes that generate the summary information you or your users are looking for (and avoid using Layout DXL).

In a similar manner, accessing History information can also be slow. Apparently, history information is stored in a separate file from the Module itself. And, when you first access the history for a module, DOORS once again creates an entire cache copy of all the history to your local machine. You'll notice if you open a module, then open object properties, the properties window (history) will come up slow the first time, but faster subsequent times. Creating a baseline will zero out the history information and make it a bit faster (of course, now you have to open a baseline to get the older history). Also, you can create a DXL function that will pre-load the history information when you open a module (which will create one longer slow period when you open the module, rather than two slow periods when you open the module and then access the history).

It's been my experience that the server/client bandwidth and the caching of large amounts of data, is the biggest impact to performance. Unfortunately, there is nothing you can do about the speed between the server and client. And, you can't avoid DOORS copying entire modules and history files to your local PC (i.e., you cannot access a specific Object without opening the entire Module). All you can do is try to minimize the traffic between the server and client, and/or manage the slow performance in a way that is a little less annoying to the user (i.e., open a bunch of modules all at once, rather than as needed).

Once the data you need is cached locally, DXL runs pretty fast.

It is possible to create some large loops or nested loops that can take a while to execute, but you kind of expect that. For example, you can have something like:

for Object in entire(Module) do {
for Link in Object->"*" do {
// i.e., check every outgoing link on every object in the entire module
}
}

But again, you expect large loops to take a while.

Dealing with performance is one hurdle. Writing DXL that doesn't crash DOORS is another
Report this to a Moderator Report this to a Moderator
 6-Jan-2009 23:28
User is offline View Users Profile Print this message


David Ofstead

Posts: 3
Joined: 9-Oct-2008

Thank you all! Really good info here. And I will certainly keep an eye out for any monkeys that start typing regedit, lol.. that was too funny.
Report this to a Moderator Report this to a Moderator
 7-Jan-2009 00:04
User is offline View Users Profile Print this message


Paul R Miller

Posts: 29
Joined: 16-Feb-2007

Originally posted by: Thomas Young

....In a given folder, if the number of LSPs gets up in the hundreds, (which can happen when all possible permutations of linked module pairs are considered in a folder containing say, 30 formal modules).....

-TY


Hi Thomas,

This number of LSP's caught my attention - are you adopting a top-down or a bottom-up link direction? I might be wrong here in your case, but the volume of LSP's that you seem to require is usually symptomatic of adopting a top-down link direction. This is one of many weaknesses with using a top-down link direction in DOORS.

-------------------------
Paul Miller
Specification Practices Specialist
EuroCyber
Melbourne, Australia
Mobile: + 61 (0) 418 135 103
http://www.eurocyber.biz
Report this to a Moderator Report this to a Moderator
 7-Jan-2009 16:22
User is offline View Users Profile Print this message


David Pechacek

Posts: 674
Joined: 5-Dec-2006

Originally posted by: David Jakad
Bandwidth is another issue, as individual modules can be quite large. When you open a module, DOORS creates its local copy on your machine, eating up network bandwidth in the process.


David as far as I know, when a module is opened, the data is sent to your local machine in its encrypted and compressed format. The actual unpacking of the data is done locally. And while a module can be large, in my experience I think only a certain portion of large modules are unpacked. I say this because when I scroll through a large module, sometimes it takes a second to load what seems like a new "section". I think this is DOORS unpacking some more of the data from the compressed version from the server.

Anyone have any actual proof of what DOORS does?

As far as working remotely, I've messed with my companies database up in Hunt Valley, MD (I'm in Charleston, SC). So its a few hundred miles. Performance was acceptable.

It definitely is nice to have 2GB of RAM. My old machine that I had until about 3 months ago only had 1GB and my hard drive was always going crazy when running strenuous DXL code.

-------------------------
David Pechacek
AAI Services Textron
dpechacek@sc-aaicorp.com
David.Pechacek@gmail.com
Report this to a Moderator Report this to a Moderator
 20-Jan-2009 23:52
User is offline View Users Profile Print this message


Thomas Young

Posts: 20
Joined: 12-Apr-2005

Paul,
You are very close. The folder uses bottom-up linking, and only contains 3 major tiers of reqmt modules (Tiers 0, 1, & 2). But within those modules are sub-tiers of reqmts (Tier 0.1, 0.2, 1.1, 1.2, 1.3, 2.1, 2.2, 2.3, etc.), and a few of the modules are cross-disciplinary ones like R&M and Standards. This situation made for a lot of "sideways linking." Since we removed the LSPs, linking has become a much more deliberate task (DXL), and performance is much better than when we had almost 900 LSPs in the folder.

Thx!
Report this to a Moderator Report this to a Moderator
Statistics
20925 users are registered to the Telelogic DOORS forum.
There are currently 1 users logged in.
The most users ever online was 15 on 15-Jan-2009 at 16:36.
There are currently 0 guests browsing this forum, which makes a total of 1 users using this forum.
You have posted 0 messages to this forum. 0 overall.

FuseTalk Standard Edition v3.2 - © 1999-2009 FuseTalk Inc. All rights reserved.