cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Learn all about PTC Community Badges. Engage with PTC and see how many you can earn! X

Arbortext Editor, Offsite Installations, and slow performance

JasonBuss
1-Newbie

Arbortext Editor, Offsite Installations, and slow performance

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
19 REPLIES 19

Hi Jason,



If you start running out of ideas you could always sniff the network traffic
to try and figure out what is going on. You could analyse the flow of
network traffic in the different scenarios and see what patterns turn up.



All the cool kids these days seem to use Wireshark:
ajordin
4-Participant
(To:JasonBuss)

Jason,

I can't help with the network issues, but if you want more info from the trace window then these acl commands are ones I use on a regular basis.
They aren't formally documented but are ones I discovered years ago and still seem to work.

I have these commands mapped to function keys for ease of use....

This open the atitrace window and outputs ACL commands....
sh atitrace &; set debug==extwin;set debug=3.27

These two output formatting info. I don't know the difference between them, I think it's just a difference in the level of output
sh atitrace &; set debug==extwin;set debug=9.1
sh atitrace &; set debug==extwin;set debug=3.1

If anyone knows of any other settings I'd be interested I trying them in the absence of a proper ACL debugging utility.


Adrian Jordin
Senior Consultant

Mekon Ltd.
Mekon House, 31-35 St Nicholas Way, Sutton, Surrey SM1 1JN.

Meet us @ Congility S1000D 2011 - May, UK:
byork
17-Peridot
(To:JasonBuss)

Jason,

I am running as a remote site and can speak to the fact that anytime I connect to the "corporate" server custom things run slower. I have always kept a local custom here that I sync. That can be done automatically with many various software tools. Probably pretty sure you know this but 5.4 has the ability to sync custom directories or something like that but I haven't used that as we are still using 5.3 as well.

When Arbortext looks at the custom directory, it is very chatty. By chance are you running any network compression tools like Riverbed or Perbit. Another thing to check is if there are any network throttling devices in place.

Hope it helps,
Brian

Brian York
-<">mailto:->
Exmark Mfg. Co.
[The Next Lazer]

Hi Jason & Adrian-



One caveat about set debug: if you use "set debug=3.27" you will get
TONS and TONS of output-too much to be useful unless you only have it
switched on for a single operation. Go ahead and give it a try, maybe
you'll be able to find the needle in the haystack, but be prepared to
end up with thousands of lines of log output just to load a standard
doctype.



As an example, with "set debug=3.27", I got a thousand lines of debug
output just for opening the New dialog and then canceling-not even
loading a document.



--Clay



Clay Helberg

Senior Consultant

TerraXML


Funny you should ask that. They did implement riverbed this year. Are
there known issues or configuration issues?

Hi Jason-



I am in a similar situation, we have a customized application that takes
a long time to open when the doctype is on a remote server, but
subsequently opens additional documents of the same type just fine. I
can confirm it is specific to the doctype location (in our case we are
using a schema), because the schema files are kept separate from the
rest of the customization. In other words, APTCUSTOM points to a local
path, but the schemaLocation attribute in the document points to a
location on a remote server. So, from that I deduce that it is either
the doctype itself or the stylesheet that is causing the delay. I
haven't had a chance to dig much deeper into the root cause or possible
workarounds yet, but will probably have to tackle that in the next week
or so. Up to now, my idea that the delay was related to the remote
doctype location was just a hypothesis, but given your similar
experience I'll consider that piece of it confirmed.



Anyway, I'll be very interested to hear if you have any luck speeding
things up, and likewise, if I come upon a solution I'll share with you
and the rest of the list members.



--Clay



Clay Helberg

Senior Consultant

TerraXML


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


Wow. That's a list. The implication is obvious, but ... can you make it
explicit?

Arbortext Editor opens/searches/reads all of these items/paths/locations?

Any explanation re: Why? Or is that obvious, too, and I'm just missing it in
my shock?


Mark,
Apologies, but I just have to ask...

Is this an April Fools joke?

Seriously?

Steve Thompson
+1(316)977-0515

My sentiments exactly! Why would AE need to poke around in Zip files. Also, everyone here has required mapped network drives.

Dave

Ummm, my sentiments exactly. If Arbortext performance becomes
unreasonably slow because of mapped drives or shortcuts to network
drives on your desktop, Arbortext has a bug; Simple as that.

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

Ok, so in the interest of brevity, I did fire up Arbortext with the
debug=3.27, opened a doc (almost 20 minutes) and started analyzing the
log.



I have located two places where it seems like the Editor gets hung up.



The first:



[pid=4204] - 19:46:03.338 - _sslist 1497 [6] if (!
_sslist::use_in_uselist(use,uselist))

[pid=4204] - 19:46:03.338 - _sslist 1311 [7] if
(== use USE_ANY)

[pid=4204] - 19:46:03.338 - _sslist 1313 [7]
local ause[]

[pid=4204] - 19:46:03.338 - _sslist 1314 [7]
local (= 'nuse' split(uselist,ause,","))

[pid=4204] - 19:46:03.338 - _sslist 1315 [7]
local 'u'

[pid=4204] - 19:46:03.338 - _sslist 1316 [7] for
(in u ause[])

[pid=4204] - 19:46:03.338 - _sslist 1317 [8] if
(== use ause[u])

[pid=4204] - 19:46:03.338 - _sslist 1316 [7] for
(in u ause[])

[pid=4204] - 19:46:03.338 - _sslist 1317 [8] if
(== use ause[u])

[pid=4204] - 19:46:03.338 - _sslist 1316 [7] for
(in u ause[])

[pid=4204] - 19:46:03.338 - _sslist 1317 [8] if
(== use ause[u])

[pid=4204] - 19:46:03.338 - _sslist 1316 [7] for
(in u ause[])

[pid=4204] - 19:46:03.338 - _sslist 1317 [8] if
(== use ause[u])

[pid=4204] - 19:46:03.338 - _sslist 1316 [7] for
(in u ause[])

[pid=4204] - 19:46:03.338 - _sslist 1317 [8] if
(== use ause[u])

[pid=4204] - 19:46:03.338 - _sslist 1318 [9]
return 1

[pid=4204] - 19:46:03.338 - _sslist 1516 [6] return
1

[pid=4204] - 19:46:03.338 - _sslist 1585 [4] return
cachedmsg

[pid=4204] - 19:55:19.755 - _docev 770 [3]
_dochook::doc_create_housekeeping(doc)

[pid=4204] - 19:55:19.755 - _dochook 694 [4] (=
Adoc_options[doc] ")

[pid=4204] - 19:55:19.755 - _docev 773 [3] local
Amonitor[]



And the second:



[pid=4204] - 20:11:55.524 - _docev 773 [3] local
Amonitor[]

[pid=4204] - 20:11:55.524 - _docev 774 [3] if
doc_callback_list(h::opHookMonitor,h::hookCreate,Amonitor)

[pid=4204] - 20:11:55.524 - _dochook 498 [4] local (=
'key' doc_option_key(doc,option))

[pid=4204] - 20:11:55.524 - _dochook 476 [5] local (=
'key' (. (. doc ":") tolower(option)))

[pid=4204] - 20:11:55.524 - _dochook 483 [5] return
(|| (== doc h::opHookMonitor) doc_valid(doc)) ? key : "

[pid=4204] - 20:11:55.524 - _dochook 500 [4] if (&& (!=
key ") (in key Adoc_options[]))

[pid=4204] - 20:11:55.524 - _dochook 502 [5] return
split(Adoc_options[key],A,",")

[pid=4204] - 20:11:55.524 - _docev 776 [4]
_docev::doc_create_notify_all(Amonitor,doc)

[pid=4204] - 20:11:55.524 - _docev 754 [5] local
'j' 'func'

[pid=4204] - 20:11:55.524 - _docev 755 [5] for (<=
j count(Acb)) (= j 1) j++

[pid=4204] - 20:11:55.524 - _docev 758 [6] (=
func Acb[j])

[pid=4204] - 20:11:55.524 - _docev 759 [6] if
defined((. func "()"))

[pid=4204] - 20:11:55.524 - _docev 761 [7]
catch((*func)(doc))

[pid=4204] - 20:11:55.524 - loaddita 122 [8] if
doc_type_dita(newdoc)

[pid=4204] - 20:11:55.524 - _docev 755 [5] for (<=
j count(Acb)) (= j 1) j++

[pid=4204] - 20:11:55.524 - _docev 765 [5] return 1

[pid=4204] - 20:11:55.524 - _docev 782 [3] return

[pid=4204] - 20:20:42.393 - _winev 59 [3]

With multiple remote offices using Arbortext Editor, we found it best to
put the compiled document types on a network drive located in each office.
More work for us, but a much faster user experience as the editor is
constantly checking and validating with the DTD.


Larry Porter
Underwriters Laboratories Inc.
333 Pfingsten Road
Northbrook, IL 60062
Direct Line: 847-664-3966
Cell Phone: 847-875-2771

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 Mark,

Thanks for the details. Did you attempt upgrading to a patched version of
the JDK?

So I ran some tests and did NOT find the problem.

I used Editor 5.3 m110 and Java 1.6.0 (build 1.6.0-b105) although I forget
which Java Editor uses for what ... 5.3 m110's own internal Java version
un-noted by me ... the version above is what's reported by Java > About Java
in Control Panel. I can't quite tell whether this is before or after the
patch reported in the bug linked to in Mark's last e-mail ... the version
formatting is different. I'm on Windows XP SP3 with 2GB RAM on a Dell
Latitude E6400.

Detailed results (should be readable if in monotype typeface). Time is m:ss.

Network Shortcuts/zips No
shortcuts/zips.
Local Custom Editor First Start 1:14 2:16
Local Custom Doc First Open 0:14 0:11
Local Custom Editor Second Start 0:06 0:08
Local Custom Doc Second Open 0:05 0:06

Network Custom Editor First Start 3:07 3:54
Network Custom Doc First Open 2:37 2:40
Network Custom Editor Second Start 1:33 1:28
Network Custom Doc Second Open 2:30 2:49

I can't imagine anyone wants the raw data ... but I've got that for
posterity's sake.

Testing Process:
1) Reboot.
2) In no particular order:
a) Connect to VPN.
b) Start Task Manager.
c) Start TextPad.
d) Open notes file in TextPad.
e) Start Windows' Date and Time Properties.
f) Wait until CPU idles.
3) Begin tests.
4) Type notes during start attempts.
5) Switch a little between various Task Manager views.
6) TextPad save notes after start or load complete.

Repeat 1 - 6 for each test.

Note: I cussed like a banshee somewhere in there after I copied all my
network shortcuts to my network homedrive, disconnected from my homedrive,
and then could not find it in Recent or Network Neighborhood after running
all the tests. Doh! Locked the keys in the car, the combination in the safe.
Fortunately corporate support was able to retrieve it somehow. (I eventually
also found it in my registry, because, you know, I kept looking just so I'd
know if I'd've survived on my own 😉

--
Paul Nagai

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

Top Tags