"AND " tag doesn't work and checking the checkbox in the tag dialog box is extremely slow

[jekaq]

hello!

I have 2 issues with Robohelp at this moment. After installing the patches, it is almost impossible to check the checkboxes for tags in the Conditional Build Tags dialog box. sometimes it takes more than 20 seconds just to select one of them...

the other problem is that when generating the Web Help with AND tag, the text with one of the tags does not appear neither in the generated .chm nor in the preview of the topic.

anyone had the same probs?

thanks

[RoboColum_n_]

It is normal for the tags to exclude not include text. Therefore if you have set-up your CHM single source layout with AND in the conditional build tag expression it will be excluded from there. If your WebHelp is set up differently, they may explain why it appears there.

As for the slow response, is your source on a local drive. It should be. Also have you applied all the patches. Perhaps you could tell us your full RoboHelp version to start with.

---

The RoboColum(n)

@robocolumn

Colum McAndrew

[Guest]

jekaq wrote:

I have 2 issues with Robohelp at this moment. After installing the  patches, it is almost impossible to check the checkboxes for tags in the  Conditional Build Tags dialog box. sometimes it takes more than 20  seconds just to select one of them...

When you say "the Conditional Build Tags dialog box," I assume you are talking about the dialog that appears when you highlight a section of text and select "Format->Apply Conditional Build Tag->New/Multiple" or right-click and select "Apply Conditional Build Tag->etc." correct? If not, could you attach a screen shot of the dialog you're talking about?

I'll explain more later, but when dealing with Conditional Build Tags it is generally a good idea to keep the "Single Source Layouts" and "Conditional Build Tags" pods closed as much as possible.

[Guest]

jekaq wrote:

After installing the patches, it is almost impossible to check the checkboxes for tags in the Conditional Build Tags dialog box. sometimes it takes more than 20 seconds just to select one of them...

[snip]

anyone had the same probs?

I promised more feedback, here it is.

Over the course of time, many complaints have been posted in this forum about the poor performance of RoboHelp. The usual response to these complaints has been "make sure that the HTML source files are on the local disk, and not a network share," and "be sure your program has been patched to 8.0.2.208." When these conditions have been satisfied, and the slow performance persists, no one can seem to offer any further advice.

I, too, have been subjected to the slow performance of RoboHelp, to the degree that at one point I recommended that the company abandon RoboHelp and seek another, perhaps homegrown, alternative.

The project I have been working on contains 63 topics (about 3.5 MB) and 62 snippets (631 KB). Not too large as policy manuals go. It also involves 9 different Condition Build Tags and 10 different WebHelp layouts, 8 of which generate output for a single CBT, one which combines two of them, and one which builds a version that has no conditions.

When it came time to document my project (which includes a user's guide on how to use RoboHelp in our particular context, as well as documentation on a couple of scripts and programs I wrote to fill in gaps in the publication process) I decided to use RoboHelp as my editor.

What I discovered was that as my project documentation increased in size, I never ran into any of the performance issues I was seeing in the policy manual.

Acting on a hunch, I created a new project and imported all the files from the old project. As RoboHelp imported the files it detected the CBTs, and added them to the CBT pod. At this point, RoboHelp performed adequately (RoboHelp has never seemed "snappy" to me; I sometimes suspect that it was written in a scripting language and is executed in a script engine rather than as a compiled program).

I then started adding WebHelp layouts to the project, each tied to a CBT, and recorded performance timings for each addition. I won't bore you with all the pages of timings I generated but here are some highlights:

After adding the second SSL (three now, counting the default WebHelp) the program started feeling sluggish. At this point I selected one of the layouts and instructed RoboHelp to 'Generate' it. From the time I selected 'Generate' to the time a confirmation dialog appeared 7 seconds elapsed. By way of comparison, now that I have all 10 layouts defined 40 seconds elapses between the time 'Generate' is selected and the confirmation dialog appears.

When I added the fourth layout I timed the interval between the moment the "New Layout" command was executed and the properties dialog appeared; 32 seconds elapsed. When adding the tenth layout to my configuration 95 seconds elapsed between the command and the dialog appearing.

As part of my evaluation, I launched the Windows Task Manager and opened the "Processes" tab, and watched for what percentage of the CPU RoboHelp was using during these periods. This is useful information, because if RoboHelp is not responding but CPU usage is low, that means RoboHelp is blocked waiting for some resource to become available (e.g. a network file). OTOH, if CPU usage is high, the poor performance is not due to infrastucture issues, but is internal to RoboHelp.

When I switched from Task Manager back to RoboHelp (mouse clicking on the title bar) I noticed that RoboHelp pegged (some would say "hogged") the CPU for a period of time during which RoboHelp would not respond to user input. When CPU usage dropped, RoboHelp again became responsive. I saw the same sort of behavior when I attempted to create a new layout but clicked 'Cancel' on the confirmation dialog. After four new layouts were added it took 20 seconds for RoboHelp to respond; now it takes 40 seconds for RoboHelp to become responsive after hitting 'Cancel'. Interestingly, it takes the same amount of time to respond after pressing 'Cancel' as it is when you simply move focus to a different window and then return to RoboHelp.

I theorize that RoboHelp is doing some sort of background validation or processing when multiple WebHelp layouts are defined, and this background process is triggered whenever the SSL "pod" receives a Windows 'OnFocus' message. To validate this theory I simply closed the SSL "pod." Lo and behold, when I closed the "pod" RoboHelp became it's usual sluggish-but-usable self.

Simply closing the SSL "pod" won't solve all the performance issues when using multiple layouts. For example, in it's current state when I select "Batch Generate" it takes over 10 minutes (yes you read that right, minutes) for the batch generation confirmation dialog to appear (all the while consuming about 95% of the available CPU). And I can offer no suggestions when you absolutely have to edit the properties of individual layouts.

My recommendations are:

1. Minimize the number of layouts RoboHelp has to track. Remove every layout from the pod you are not using, and combine them when possible.

2. Keep the SSL pod closed whenever possible.

3. Hope that Adobe programmers look more closely at the whole SSL/CBT interactions and improve the design and implementation of that particular feature.

I've entered a defect report on this issue on the defect tracking area of this site, but that form does not allow enough input to adequately explain the problem. Hopefully this post will attract their attention at some point.

HTH

Cheers,

Lee

[Captiv8r]

Hi Lee

A25CharacterScreenName wrote:

...The project I have been working on contains 63 topics (about 3.5 MB) and 62 snippets (631 KB)...

Just curious here. Why is there nearly a 1:1 ratio of Topics to Snippets? That seems more than a bit odd to me.

Cheers... Rick

Helpful and Handy Links RoboHelp Wish Form/Bug Reporting Form Begin learning RoboHelp HTML 7, 8 or 9 within the day! Adobe Certified RoboHelp HTML Training SorcerStone Blog RoboHelp eBooks

[Guest]

Captiv8r wrote:

Hi Lee

A25CharacterScreenName wrote:

...The project I have been working on contains 63 topics (about 3.5 MB) and 62 snippets (631 KB)...

Just curious here. Why is there nearly a 1:1 ratio of Topics to Snippets? That seems more than a bit odd to me.

Cheers... Rick

Well, the glib answer is that the technical writers designed it that way (I'm just a programmer, I do what I'm told).

But perhaps a more useful response is to explain what we are doing. We are creating an online Credit Policy manual for a major national bank (well, I'm helping the vice-presidents who are creating it). The national bank has affilates in 8 different states.

So let's say the bank has a corporate policy regarding collateral that applies to all loans. This policy applies to consumer loans, business loans and real-estate loans. By putting this policy regarding collateral in a snippet it will be be included in the policy manual for each of these business areas, but more importantly the policy itself is stored in a single area so we can be assured that if the policy changes those changes will be reflected everywhere.

As it turns out, this use of the product has resulted in a snippet-to-topic ratio close to 1:1. I suspect that our VPs have may have over-used the snippet feature, and some small refinements could be done, but on the whole I think the product is being used precisely as it should be.

Now assume that one state's regulators mandate a minimum loan-to-value ratio for collateral on loans in their jurisdiction. We can add a Conditional Build area in the snippet to distinguish these ratios for different affiliates, and we expect that those Conditional Build areas will be respected when the manual is generated for a specific affiliate.

I think our project is a great example of what can be done using all the features of RoboHelp HTML. Unfortunately, it has also revealed many of the shortcomings that currently exist in the product. I suspect that Adobe's QA group simply didn't stress the product the way we are doing.

FWIW, our project does not contain any proprietary or trade secret material. If we had reasonable assurances from Adobe that the project would find its way into the product development team, I think I could convince the Powers That Be that the entire manual could be sent to Adobe for development and testing purposes.

[MeWrite]

Lee -- I wrote up the slowness issue last year too regarding the SSL pod.  The more layouts the slower it gets.  I've talked with Adobe support twice and have several emails going back and forth.  The end result according to Adobe: it's something wrong with the our computers (5 of them) or the project is corrupt and delete the RegKeys (I don't recommend this.  This is not logical to me since it also occurs on brand new projects.)

For anyone else that has this issue with the SSL pod, closing the pod works until you need it.  Unfortunately, between a test server and a production server with 15 roles (30 webhelp pro layouts) and 5 print layouts, there's nothing to be done, but get coffee while the SSL pod thinks.  The IT departement and I have been all over RH trying to find out what RH is looking for and to date we cannot find out why adding more than 4 SSLs is an issue in RH8.

Does anyone know if RH9 has this same issue?

CJ

[Peter Grainge]

If I recall correctly MeWrite, I tried with your projects as did Adobe and the problem was we could not replicate the problem. If I am thinking of the correct thread, I could happily keep adding layouts with no adverse effect.

I agree that then stating it is your environment is a bit like circumstantial evidence. Unfortunately without being able to replicate the problem and without lots of others reporting the same issue, it does tend to point that way.

Testing your projects in RoboHelp 9 would almost be pointless as I couldn't replicate it in 8.

Out of curiosity, could IT set up a standalone machine not connected to the network and with virus protection and firewall disabled? If they could, then does the problem go away. Maybe we tried that before. I suspect we covered how IT install RoboHelp and indeed build the PC. If they use images, it might be worth trying installing from DVDs.

I wish I could come up with something fresh but this is just not a common problem, not that it helps you to hear that.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[Guest]

MeWrite wrote:

Lee -- I wrote up the slowness issue last year too regarding the SSL pod.  The more layouts the slower it gets.  I've talked with Adobe support twice and have several emails going back and forth.  The end result according to Adobe: it's something wrong with the our computers (5 of them) or the project is corrupt and delete the RegKeys (I don't recommend this.  This is not logical to me since it also occurs on brand new projects.)

I agree; this seems to me like they are grasping at straws. If the response was, "we've looked at our code and see that it is going out and examining the registry then we're not detecting when bad data is found," then I would be inclined to accept their explanation. If all they can say is "we don't understand why it might be happening, but try this" . . . well, I wouldn't.

Nor do I buy the line that "this is an extremely rare problem." If you actually count the number of unique posts on this issue here and in the main RoboHelp forum I would guess there have been 4-5 reports of this problem from different people--which in this kind of forum is significant. When Adobe support says that it is rare, I suspect that what that means is that it is rare for people to use RoboHelp with more than 4 SSLs of the same type. Among that group I suspect that it is virtually inevitable. But even if it is rare, the fact that it has come from the 3 independent sources that I can think of off the top of my head means that there is a bug in RoboHelp; the bug may be that they haven't adequately dealt with hardware edge cases, but it's still the fault of Adobe, and not the hardware manufacturer. I expect any software, even my own, to be more robust than this.

It is common in cases like this for support to blame the problems on network connectivity. In this case, I doubt very much that the network is responsible. In my own case, everything is local to my machine, except of course, the ftp destination and the Subversion repository.

To test the network theory, the first thing I did was to simply unplug the network cable from the machine. No difference in performance. Next, I left the cable plugged in, but disabled the network connection. No difference in performance. Lastly (and perhaps most revealing)  I started up the Task Manager and followed the performance profile of RoboHelp during this process. I discovered that when these time consuming SSL functions start RoboHelp virtually "pegs" the CPU, consuming 95-98% of the available cycles. If it were waiting on a network resource (or even just reading from the hard drive) this would not happen; when waiting on a network response, the CPU should go quiescent while waiting. The same is true with hard drive access: the speed of the CPU is so much greater than the transfer rate of the hard drive that even database applications rarely consume more than 50% of CPU time. I don't know what RoboHelp is doing in the background, but it's clearly doing something. During this time I can actually hear my cooling fan accelerate as it tries to cool the CPU from its over-exertion.

One thing I did note is that if I shifted focus to another application (trying to be productive while RoboHelp spins), and then returned to RoboHelp when CPU activity slowed, the CPU would peg again, and it would be 40-45 seconds before RoboHelp became responsive. Simply shifting focus to a different application and then back again caused RoboHelp to go into this "wait" mode.

For anyone else that has this issue with the SSL pod, closing the pod works until you need it.  Unfortunately, between a test server and a production server with 15 roles (30 webhelp pro layouts) and 5 print layouts, there's nothing to be done, but get coffee while the SSL pod thinks. The IT departement and I have been all over RH trying to find out what RH is looking for and to date we cannot find out why adding more than 4 SSLs is an issue in RH8.

Based on the behavior of the CPU, I suspect that RoboHelp isn't looking for anything at all. I also suspect that simply adding layouts is not enough to make this behavior happen but adding Conditional Build Tags to the documents and the layouts is also required, although I have not tested this and can neither confirm nor deny it. My current theory (subject, as always, to change) is that with multiple layouts RoboHelp is doing some sort of background validation of the project when certain events happen. One of these events seems to be when the SSL "pod" simply receives a Windows OnFocus message.

A while back I did a set of timings on this, and it seems that the slowdown increases as SSLs are added, and not linearly. The exponent is some value greater than 1, but less than 2. It could be a Fibonacci sequence. My experience also suggests that 3 is indeed the magic number. It's at SSL 4 that the slowdown starts becoming noticeable.

FWIW, Adobe's fancy paper-oriented formats simply do not interest me, so I haven't done any testing with PDF or Air--and will not. Our project is strictly HTML, and the SSLs are strictly Web Help--not Pro and not Microsoft CHM.

Luckily my situation is not as dire as yours; we have only 9 Web Help SSLs, and 9 unique Conditional Build Tags. My last recorded timing shows that between selecting "Generate all" and the time the batch generate dialog appears is only 10m50s. Enough time for coffee, but not enough to get much web shopping done :-).

Does anyone know if RH9 has this same issue?

Hoping that RH9 might have been a performance improvement I installed a trial version and moved a copy of my project to it. If anything, the performance is worse and simply closing the SSL pod no longer works to improve performance. There's also a lot of HTML rewriting going on "under the covers" that troubles me. So far all I have seen is unnecessary <span> tags (which I now no how to make disappear without actually having to edit the HTML) but it is worrisome nonetheless.

For some people new features in RH9 may make it advisable to upgrade, but for my project (and I suspect for yours) I see no upside, and some real downsides, to moving to RH9.

[MeWrite]

Lee -- thanks for your thoughts.  Since my current client just purchased RH8 last May, I think recommending RH9 would not be wise and unless someone came back and said that RH9 defintely fixed the SSL pod issue and a couple other issues we're experiencing with WebHelp Pro layouts.  I wouldn't travel that path with so many unknowns to a new version.  I've never been big on upgrading the moment the new version is out anyway.

I have tried all the same steps that you did (and pretty much in the same order) with the same results.  I should claify one thing though that I was remiss in mentioning.  It's not the amount of layouts that is the issue.  It's the amount of server links in the Server Properties box.  We still have 1 Layout per Role, but only 2 Server links (1 to production and 1 to development).  All we have to do now is select the layout then change the area before publishing and it will push the correct TOC and conditional tags for that role.

Regards,

CJ

[Guest]

MeWrite wrote:

[snip]

I have tried all the same steps that you did (and pretty much in the same order) with the same results.  I should claify one thing though that I was remiss in mentioning.  It's not the amount of layouts that is the issue.  It's the amount of server links in the Server Properties box.  We still have 1 Layout per Role, but only 2 Server links (1 to production and 1 to development).  All we have to do now is select the layout then change the area before publishing and it will push the correct TOC and conditional tags for that role.

I wonder how this observation might apply in my case. We are not using WebHelp Pro; rather we are using standard WebHelp and pushing the output to 2 ftp servers, which are then exposed to the 'net via a load balancer. Thus, our final property page looks like this:

There are two FTP servers, and each affiliate gets it's own sub-directory, so I have 18 different "servers" (actually server paths) in the list, only two of which are used for any particular layout. We are still in the final stages of deployment, so this is the development/test environment; when we go to production this list will double again to 36 server paths.

I'm having a hard time reconciling this network setup with the CPU pegging, but I'm willing to experiment. As soon as I get a chance, I'll go through and delete all of my output paths except one, and try to measure how that affects performance. I'll post the results here when I have something to report.

Cheers,

Lee

[Jeff_Coatsworth]

Just curious - what happens if you take all the FTP crap out & just generate to a different local folder? Is the performance any better?

[Peter Grainge]

Unless in a quick read having got home late I have missed a fundamental here, the game has changed. We were all looking at the number of layouts as the issue whereas the problem is large numbers of publish locations in one layout, correct?

I cannot respond on that but I'll see if I can find someone who can.

On upgrading, I doubt that has changed this issue but one reason for upgrading from 8 to 9 is the upgrade price has been fixed lower than usual. That might help if other features are of use.

---

See www.grainge.org for RoboHelp and Authoring tips

@petergrainge

[MeWrite]

Lee -- yes we have the same issue.  We have a test server and a production server so 16 roles became 32 for us. I am curious to see if you strip out just the URLs, not the layouts, if you see the speed issue resolved. I figured this out when I deleted the layouts, but the speed did not resolve itself.  That's when I realized that the URLs were still there even after the layouts were removed.  Which indicated to me that the URLs are independant of the layouts.

Jeff -- without the URLs our speed returns and we can generate the files locally, but we can't move the files to the server.  With this client, we are not allowed direct access to the server (it's a bank thing :-).  The only way to get our files out there is through the publishing option in RH.  At this time IT is busy with rolling out the software and fixing issues so that I cannot use them to move out help files every time we update.

Peter -- no you did not miss the lane change.  I was not clear in writing this issue up in this thread or my original thread.  It is not layouts that are the issue.  I can have 32 layouts, it's the fact that each layout points to a different URL.  For example:  Processing Help publishes to <testserver>/Processing Area and Underwriting publishes to <testserver>/Underwriting Area, etc...  When production comes online, our help will double the URLs so that testing and production mirror each other.

The RH slows down with each URL after the 4th one is entered.  I had about 10 URLs in there before RH really had issues and batch generate stopped working altogether.  Our solution is to have 2 urls, one for each server then publish each project one by one changing the area as appropriate.  It's tedious and a little bit time consuming, but still much faster than publishing with 32 URLs defined.

On a side note, Adobe Support called me today to see what I was talking about.  I shared my desktop with them and recreated the URLs so that they could see the speed issue.  I think after seeing this they finally understand it's not a publishing issue which before now is what they kept thinking, versus the defining of the server path which I believe is the real issue.  The tech said that he would research this and call me in a couple of days to tell me what he finds out.  When I hear back from him I will update this thread.

[Jeff_Coatsworth]

Good to know - just reinforces my belief that the FTP client in RH is pretty lame. I'm not sure why you wouldn't just batch generate to different folders locally & then run a real FTP program to batch upload them to their proper servers. I don't ask my word processor to design spectacular web pages, so why would I expect RH to be any good at FTPing? Just asking ;>)

[Guest]

By George, I think you've got it!

In RoboHelp, the list of publication servers is stored in an XML file named "pblsvrs.sss". I made a backup copy of this file then removed all of the <section> elements from the <configuration> root. When I restarted RoboHelp performance improved to the point that while it could not be considered snappy it was adequate. No changes were made to the list or application of Conditional Build Tags, nor did I remove any of the 10 layouts.

Experimentation also shows that I could rename the two files while RoboHelp was running and it would have an immediate impact on performance. For example, I would rename "pblsvrs.sss" to "pblsvrs.sssnew" and then rename "pblsvrs.sss.old" to "pblsvrs.sss" and would immediately experience a 45 second delay when returning focus from the File Explorer to RoboHelp. Upon reversing the renaming process RoboHelp would become responsive within a second of receiving input focus. It is obvious that RoboHelp reads this configuration file regularly (e.g. when it receives an OnFocus message) and does not cache the data internally.

Without publication servers specified, File->Generate->Batch Generate displays the "Batch Generate" dialog in 35 seconds. While this is not particularly fast, it really beats the 10:50 that it takes when publication servers are specified.

I'm still hung up on the question of why this change would cause the CPU to "peg" during the delay cycle. It's possible that when RoboHelp gets whatever signal it does to read the "pblsvrs.sss" file it runs through the list and attempts to make a connection to each server URL to see if it responds (despite the fact that the actual host portion of the URL is repeated). Using Winsock, the 'connect()' method is not a blocking call; it returns immediately with some sort of return code indicating the status. If the return code is WSAEWOULDBLOCK the program should then call 'select()' which will block until the connection completes or a timeout expires. Programmers new to socket programming will sometimes neglect using 'select() and will simply put the 'connect()' call into a tight loop, calling it repeatedly until it either succeeds or a timeout value is exceeded. This kind of programming could cause the CPU to "peg" (and could actually lock up a non-preemptive Operating System, like MS-DOS or Novell Netware). Should I find any spare time I might fire up Wireshark and sniff the line to see if there is network activity when there shouldn't be.

Knowing what I now do, I'm a little uncertain as to how to proceed. Jeff's suggestion to "route around the damage" by doing the publication outside of RoboHelp is not bad, and my bank apparently isn't as concerned about poking a small hole in the firewall for known workstations as yours is, but as soon as this project is stable it's our intention to turn RoboHelp over to a couple of bank vice-presidents to use, and you know that most executives don't know the difference between FTP and FTD. My department's goal was to find third-party off-the-shelf software that we could give them and then get out of the software development and support role for this project. I'd probably have to write some dumbed-down interface that they could excute with a single click to do the publication outside of RoboHelp, at which point we're sliding back into custom programming and maintenance.

I can do it if I have to, but a fix to RoboHelp from Adobe would be a much better solution. Any other suggestions or insights would be appreciated.

[MeWrite]

Update:  I have spoken to Adobe Support twice.  The first time they came back as stated that they could not duplicate the issue, therefore it must be something with our computers and/or server.  When I pointed out there were several people with the same issue (see this thread and a couple of others), I was told they would research it and get back to me.  I even did a remote session to show them how and when it got slow, so they could see it was occuring and that at least 2 of us could duplicate the problem consistently.

So far, I have not heard anything back after the 2nd call and remote session.

CJ