TS4.1 WinXP SP3, IDE slow response *only* if mapped drive file opened from within teststand....?

[AndyWatt]

I've got a strange situation here. First I should describe the system:

• 2 Win XP SP3 machines, both with TS4.1 IDEs installed
• Machine 1 has common sequence file logic, which is shared with both machines via a mapped drive "T": Sequence files are in "T:\Logic"
• Both machines have search paths with the root of T: as the last path in the search list.

Editing on machine 1 is fine - seq files can be opened from within teststand, navigated around, etc with no issues.

However, on machine 2, the IDE behaves normally ONLY if you drag seq files in to edit, or double-click to edit. As soon as you open a sequence file using TestStand's Open Sequence File dialog, clicking anywhere on the IDE sparks a large volume of network traffic and the IDE "hangs" for several seconds (I've seen as long as 5) and is completely unresponsive (there's a direct correlation between the "spike" in network traffic ending and the TS IDE becoming responsive again).

I've done some netstat -ano queries and I don't see new ports opened up, so all this is being poured through the regular windows file sharing link. If I open direct from the T: drive, that's also the case...

Also - this problem isn't continuous: it's been fine for several weeks, and came back yesterday. I was lucky enough to find the "don't open any files from inside teststand" workaround and continue working normally.

If you have opened a file within the application, then you Exit TS and restart it, and all is well again.

Any ideas??? It's getting INCREDIBLY ANNOYING.

[~jiggawax~]

In your Search Directories where is the mapped drive located?  Network and shared drives should be at the bottom of the list. 

How big is the mapped drive?  Do you have the Search Subdirectories turned on?

Move it to the bottom of the list and see if that helps.

Cheers,

[AndyWatt]

Hi Jigga - thanks for the response!

Here's the deal - the system is a "Test n Ready" system, and our admin privs don't unfortunately allow us to change the search directory settings. However, the guys at ServiceForce have already got your points covered - here's the list I see:

• (ticked) Current sequence file directory
• (ticked) Current workspace directory (<none loaded>)
• (unticked) Application directory
• (ticked) TestStand directory
• (ticked) TestStand bin directory
• (unticked) Initial  working directory
• (ticked) Windows system directory (DLL, EXE file ext)
• (ticked) Windows directory (DLL, EXE file ext)
• (unticked) PATH Environment variable
• (ticked) TestStand public directory
• (ticked) Adapter support directory() (Subdirs) (status = "Not found")
• (ticked) public components directory (Subdirs)
• (ticked) TestStand components directory (Subdirs)
• (unticked) D:\Reports
• (unticked) T:\Logic (Subdirs) (SEQ file ext)
• (unticked) T:\Data (Subdirs) (TDF file ext)
• (ticked) T:\ (Subdirs) (SEQ file ext)
• (ticked) C:\MC-TAS (Subdirs) (SEQ file ext)
• (ticked) C:\MC-TAS\GIP\LLB

Then again, looking at that they've got a local directory after the networked drive (T:\). Do you think this could be a source of the problem?

[dug9000 · Accepted solution]

That's probably the problem. Searching subdirs, especially on a networked drive should generally be avoided.

I'd recommend against using the "search subdirs" options, even in the non-networked case, since, not only can it lead to performance problems, it can lead to unintentionally using the wrong module because which module you mean, if you just specify the file name and rely on recursive searching, could be ambiguous and have more than one possible match. It's better to use a fixed search directory with a partial relative path if possible. For example, if your search directory is c:\mc-tas and you want to reference a module in GIP\LLB, you could just specify GIP\LLB\Mymodule.llb for the path in your steps and you would then not need to make c:\mc-tas a recursively searched subdir.

Hope this helps,

-Doug

[AndyWatt]

Ah, Doug, that's a great help. I'll pass this information to ServiceForce and see if we can get a resolution based on it. I don't think it'll be tricky, our work consists of a layered framework with testcases sitting on top, so it might actually help the organisation of the sequence files and make things less potentially confusing, both for TestStand and engineers.

Thanks again

Andy