Community Tip - Did you get called away in the middle of writing a post? Don't worry you can find your unfinished post later in the Drafts section of your profile page. X
Hi Jason,
Some users that I support had performance issues a while back and I worked with PTC support on it. They were really helpful. If someone from PTC is reading this, please give Catherine Koning a medal!
The issues were related to startup time for Arbortext on Windows XP boxes. This may not help your case, but here were our findings:
+ Ensure that you do not have any zip files saved on your Desktop. Save them to some place like C:\zips instead. Do not save them to the root folder in your C or network drive.
+ Ensure that you have no shortcuts to network drives on your Desktop.
+ Ensure that you do not have any mapped network drives on your machine. Shortcuts in My Network Places do not have any adverse effect.
Support finally got me to install Process Monitor and helped me to analyze the logs.
You should find it at this address:
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
If this does not work for some reason, ask your favorite search engine to locate "process monitor".
I hope that helps and good luck.
-Mark
We have similar issues here in the states, but usually less lag time. Our virtual servers are in another state. For us, the first load lag of the day is 3-8 minutes...then is ok every time after that. Our small off-site office sounds more like your India lag times, although they have problems with everything, not just Arbortext, so they seem to add in the usual office netword connectivity issues.
The only thing PTC mentioned to us was turning off applications we weren't using by renaming or deleting the directories under "application" (DITA and SMA). That did not help -- and the directories get reloaded on each maintenance fix install.
There is certainly no way we could un-map all our drives! Sometimes I personally will have C-Z all mapped.
Since we use the PE, I have not had any luck with copying the custom doc type locally - it still bops off and reads the PE...while we twiddle our thumbs...
John T. Jarrett
In Reply to Jason Buss:
Hello, I'd like to pick the lobes of those of you who have had
experience with supporting offsite (particularly offshore) Arbortext
installations.
Basically, I am supporting a set of authors in India, who up until 3
weeks ago, were using a custom directory on one of their servers that I
kept r-synced with a custom directory on a US server. We are using
Editor 5.3 M040 on WinXP SP3 PCs, most are new (dual-core, 2G RAM or
better). We are working with an in-house developed DTD and FOSI.
We have recently gotten them access to our test server with the custom
directory we use to test changes before migrating to production, which
is a server located in the US.
What I am experiencing is starting the India Editor can take 1-4 minutes
on startup when loading with the US server custom directory. If the
India Editor is pointing to the India server custom directory, Startup
time is less than a minute.
Where things get really odd is once I get the India Editor open when
reading from the US server custom file, opening the first XML file takes
in the area of 7-11 minutes to open. Once I get that first document
open, I can open any document of the same doctype in 8-15 seconds. It
acts as if it's caching the doctype, and taking a ungodly amount of time
doing it.
I tried this both with the author logged in while I watched over webex,
and I tried while logged in myself (being an admin, I was trying to
eliminate possible access issues). This made no difference on
performance. I also tried loading a document both connected and not
connected to the PE server, this also made no difference in performance.
If I open an XML document authored with a different doctype, that first
document will also take 7-11 minutes, and 8-15 seconds for each
subsequent document.
I also took the custom directory down to the bare bones, no ACL, no
customizations of any kind except for the DTD, FOSI, and DCF. Catalog
file with one entry for this doctype. No discernable change in
performance.
The other oddity is if I point my APTCUSTOM at the custom directory on
the India server and start my US Editor, I have no performance issues.
Now, I have noticed, if I VPN into my network and try to start
Arbortext, it will spend 20 minutes initializing unless I take one
particular entry out of my catalog file. This entry points to a catalog
file on a UNIX share accessed through a Samba mount point. I also tried
this with the India Editors and it made no difference.
I also opened several other apps, opened files on both US and India
servers, but Arbortext seems to be the only one getting hung up trying
to startup and open documents. I was able to access all files for the
documents and the custom dir from the command line, so I don't see any
access issues.
Basically, I'm tired, cranky, and just looking for clues that might
point me in the right direction to troubleshoot this. What have other
folks been seeing? Are there any particular problems with, for
instance, samba shares? system-funcs in FOSIs? It just seems like
there's something I am missing here, but i've been benchmarking and
chasing this for a week, and it's starting to become a blur.
Also, does anyone know of a way to run Editor in a "debug" mode? I
found the atitrace.exe file in the bin with the epic.exe, but starting
it up provides almost no information (basically startup and quit). Is
there a flag, or setting, or environment variable that I can adjust to
turn up the logging? I'm really stumped here, and I have a requirement
to get these authors running on our test server.
Any and every idea and suggestion is greatly appreciated...
-Jason A. Buss
John T. Jarrett, CDT
BAE Systems | Arbortext w/PE version 5.4 | LOGSA XSL-FO v 1.7
The issue with zip files was related to a JDK bug - http://bugs.sun.com/bugdatabase/view_bug.do;?bug_id=5050516
We use Resource Manager heavily and, due to this bug, it sometimes got slowed down by zip files that it encountered. The workaround was to move the zips or turn off windows zip integration.
The response from Arbortext on 7/29/2009:
There is a known issue with the java method that builds the directory listing. It can cause an entire .zip file to be parsed if the Windows Zip integration is active (which it is in XP and later by default).
It is your choice whether to perform the easy solution (remove zip files from the Desktop) or the more permenant solution (turn off Windows Zip integration).
To disable the Windows Zip functionality you can run the following at a Windows Command Prompt:
regsvr32 /u %windir%\system32\zipfldr.dll
-Mark
Hi Paul,
I did not try a later JDK/JRE as I don't believe it was fixed when I was troubleshooting this. We were able to handle user performance issues by moving zip files and/or disabling Windows zip integration.
-Mark
Hi Adrion,
Could you please explain how to use
sh atitrace &; set debug==extwin;set debug=9.1
sh atitrace &; set debug==extwin;set debug=3.1
and what is the use of it? how is it different from debug=3.27
Thanks and Regards,
Suresh