• Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
    Dedicated community for Japanese speakers
  • 한국 커뮤니티
    Dedicated community for Korean speakers
Exit
0

TOC/Index slow to load

New Here ,
Jan 18, 2007 Jan 18, 2007

Copy link to clipboard

Copied

Hi all,
I have just followed Peter Grainge's methods for splitting a large project, and creating merged webhelp (thanks Peter!).

Everything is working as expected, except when the webhelp is first called the TOC and index take about 3 seconds to load from the UK. This increases to over 12 seconds in New York, which is pretty unacceptable.

When we had one large project the appearance of the TOC was instantaneous here in the UK, and much quicker in NY too.
Does anyone know if it is possible to speed this up?

I am publishing with Optimize Speed For Web Site, and I've tried excluding the Java Applet but this made no difference (I thought it might cut out some of the processing time). The actual help topic in the right pane appears instantaneously.

Many thanks,
Kate

Views

1.9K

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 19, 2007 Jan 19, 2007

Copy link to clipboard

Copied

You are experimenting with the settings that impact on speed so if they are not having any effect, my thinking is that this has to be a network issue.


Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 19, 2007 Jan 19, 2007

Copy link to clipboard

Copied

I have experimented some more and discovered that the slow appearance of the TOC is something to do with RH's process with merged projects. This involves some output files called: whproj.js, whproj.xml, and whproj.xml. If I remove the information about the merged projects from whproj.xml, and whproj.html the TOC is no longer generated (not surprisingly).

Interestingly, if I recreate the index by moving the information from the subprojects' whtdata files into the parent project's whdata files (changing the paths of the links accordingly) the TOC appears without any delay.

Unfortunately this doesn't really help me, because it's not feasible to have to maintain the index by hand. But I might look further into it to see if there's a compromise somewhere along the line.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 19, 2007 Jan 19, 2007

Copy link to clipboard

Copied

Some further info: whproj.js compiles the TOC from the subprojects whdata files. To do this it adds the files, and fixes the topic links. So I guess it's not surprising that there is a delay in showing the TOC because when the webhelp is called it has to be built from scratch.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 24, 2007 Jan 24, 2007

Copy link to clipboard

Copied

Unfortunately, short of rewriting RoboHelp's javascript, there is no way that we can speed up the TOC/index for our merged webhelp. Back to one big project 😞

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 24, 2007 Jan 24, 2007

Copy link to clipboard

Copied

I don't know why you are having these issues as a merge of 12,000 topics works fine for me and I know others also have no performance issues. As I said at the beginning, the fact that this works for you on one server but not another points to the network as far as I can tell.

Please feel free to email me screenshots of your wizard settings. You can contact me via my site.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 30, 2007 Jan 30, 2007

Copy link to clipboard

Copied

Thanks for your reply. I'm not sure I've explained myself very clearly. We tried the merged webhelp projects on the same server as the single large project. The server is in the UK, which is why New York get slower response times than here.

The single large Robohelp project TOC and index was much quicker to load in both the UK and New York. The merged webhelp projects TOC and index were so slow to load in the UK and especially in NY that we had to abandon that method.

I tried all permutations of Wizard settings but none of them made any difference.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 30, 2007 Jan 30, 2007

Copy link to clipboard

Copied

I am not surprised that there is a difference in the timings of a merged project against a single project but I would not have expected it to be significantly different to the point of being unacceptable.

Whilst Optimise for Web Site is correct in your case, have you tried the other setting?

If I get a chance, I will upload a large merge to my website and see how that performs. Although I am UK based, the website server is US based.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Jan 30, 2007 Jan 30, 2007

Copy link to clipboard

Copied

We did try the other setting with the reasoning that, although the files are larger, there would be fewer files for the server to deliver. But it made no noticeable difference.
I was wondering whether Robohelp 6 might be better...it claims to have improved publishing capabilities.
Thanks for your help...it would be interesting to see if you experience the same delay. Is your 12000 topics merged project delivered on a webserver?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 31, 2007 Jan 31, 2007

Copy link to clipboard

Copied

The publishing abilities are only about getting the output onto the target server, not how they perform when they are on the server.

Our help is set up on many servers and I will need to ask our installation people tomorrow whether any of the installations are webservers.

Hoping to upload some merged help to my site later.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Jan 31, 2007 Jan 31, 2007

Copy link to clipboard

Copied

Please email me offline via my website.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Jan 31, 2007 Jan 31, 2007

Copy link to clipboard

Copied

Some things to consider:

I also notice that a large merged project loads OK, up to displaying the welcome topic.

The TOC sometimes is a little slow, and a large index and search database can take awhile.

It wasn't always this way. I've surmised the server is busier than it use to be.

Also, WebHelp output raises a lot of red flags with html and JavaScript checkers. Some of them may be related to slow loading.

I routinely make these fixes:

whdata/whftdata0.htm
It's missing a </body> tag before </html>

whdata/whftwdata.htm
Same as above

whfdhtml.htm
Has </head> not followed by <body>. Either move </head> down to nearly the end, or insert <body> and then near the end, insert </body>

whtdhtml.htm
Has head and body sections with a block of scripts between them. Should be in one or the other.

whskin_tbars.htm
Has no proper <body> tag.
Same for
whfform.htm

Also have a look at the launch file,
myproject.htm
After the </head> there are scripts not enclosed in a head or body section. I move </head> down, just before the framesets.

whskin_tw.htm
No <head> ... </head> tags before and after the block of scripts.
same for:
whskin_frmset01.htm and ...10.htm.

whskin_plist.htm

A couple of timeout/reload pieces may be involved.

in whstart.js, near the top, is a reload value 5000. Try 2000.

In whtbar.js, just a few lines from the end, is a function tryReload
Comment out the documert.location.reload line like this:


// document.location.reload


As usual, I must caution that this seems to work while not introducing new problems in my enviroment(s) . It may not be the same for you

Harvey

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

Thanks for publishing your webhelp Peter. I get similar delays when I access that...about a 10 second delay for both the index and TOC.

I tried your suggestions Harvey, and I see a slight increase in the loading time for the TOC, and the Index seems to be a few seconds faster which is very promising. Do you make these changes in just the parent project or in the subprojects as well?

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

Hello,

I have been following this thread with interest — Me and my colleagues are working on the conversion of several WinHelp projects to WebHelp and we are having issues with very slow navigation in the merged help, (especially with searching) both locally and on a server.

Because of the nature of our company's products, we're starting with over 200 merged child help projects, and we're trying to avoid consolidating them unless there is no other option. Our testing seems to indicate that the number of projects is the main reason for slow navigation in this case, so I'd like to know if anyone has encountered a limit for how may WebHelp projects can be effectively merged with RoboHelp and/or if anyone has any suggestions for troubleshooting.

As a side note, we are working with Peter Grainge’s methods for merging WebHelp and have also been trying the other suggestions in this thread, but it appears that the number of merged projects is the main issue. Also, we've looked into some great third-party search options (such as ZoomSearch), but due to limits on the number of third-party DLLs we can ship with our products, this will probably not be an option for us. Any thoughts on this would be greatly appreciated.

Thanks,
Nick

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

I am not sure I would agree that it is the number of projects. The merge I pointed Captikate to has only eight projects but it does have around 12,000 topics. I just tried opening one of the projects with just 4,000 topics and that is considerably faster. On balance my money is on the number of topics. I'll do some more testing later.

ZoomSearch doesn't require you to ship any DLLs so I don't follow that comment.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

OK, thanks. I should have mentioned that we are working with about 5400 topics. Also, it looks like I have the wrong info on ZoomSearch - Thanks for the clarification - though my team is still focusing on trying to get the default search to work. With our current merged projects, the search takes over a minute (locally and on a server).

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

Just to be safe, I do it everywhere these files exist.

Did I emphasize that these are output files from RH X5.0.2 build 801?
You need to watch what happens when you recompile and republish. In my case, RH seems not to mind, or doesn't know, that I've changed a particular output file, and if it has no internal reason to overwrite it, RH leaves it unmolested in the published directory.

As an aside, I see some places where RH dynamic html code seems to be inserting tags on the fly, but I don't know enough to analyze it. And I'm not sure that dynamic html carries through on all browsers -- let alone Internet Explorer after V 5.5.

Sometimes I wondered why certain files were being overwritten, because I thought they hadn't changed. Then I found that, indeed, some of the housekeeping code needed to change because I had done something with the TOC, for example. So I have to make the changes again, in the newest output.

In one merged project, I give users optional access to the subprojects individually. In this case, the subprojects are release notes that can stand alone, and the merged project lets them use the master TOC, Index and Search to look at "what's new" for a number of years back.. This definitely requires all subprojects to be patched.

Another point:

You can find some of the "defective" files, if that's what they are, in the RH program folder RoboHelp Office/RoboHTML/WebHelp5Ext. These are templates where you can fix tags for some files and expect the patches to carry through to output. As I've said in earlier posts, I can't be certain they make any difference but they don't seem to hurt.

You may find that Adobe fixed some or all of this in RH6.

Regards,

Harvey


Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

I have 7 subprojects with around 2500 topics. For us, the performance issues with the TOC and index only occur when accessing the help from a webserver. When I access it from a network drive it is almost as fast as the single large project.
I haven't looked into the speed of searches until now. I get about 2 seconds for a search on the single project, and a whopping 18 seconds on the merged webhelp. This time, however, the search is just as slow on the network as on the webserver.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 05, 2007 Feb 05, 2007

Copy link to clipboard

Copied

The mode for generating WebHelp may be relevant to download speed..

I forget who tested this and reported that it didn't matter.

Nonetheless, if you haven't tried this:

If you are optimizing speed for Web Site (Internet), how many files do you have in the output folders whdata, whgdata, and whxdata?
If you do it again, optimized for Local PC or Intranet, how many files?

Does it make any difference for Web connection vs. Network access?

Also, I assume you are selecting the option DHTML > Java Applet > Pure HTML.

If not, does that make any difference?


Another question: Is the Network drive located on site, or someplace far off?

Harvey

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 06, 2007 Feb 06, 2007

Copy link to clipboard

Copied

Hi Harvey,
I tried all the different settings but they made no difference. When optimizing for web site we had hundreds of files (<10kb each) in the WHXDATA folder, and other output folders. When optimizing for Local PC these were reduced to one of each instance (about 200kb each). I had the guys in New York test the download speed of both and they got the same times.
I also tried the different Navigation Pane Preferred Formats but that made no difference either - except for Pure HTML, but that setting produces webhelp with very limited functionality.
The network drive is located on site. The funny thing is that I publish files to the network drive and the webserver gets the files from there...i.e. I don't FTP the files directly to the webserver. I don't know whether this will have any impact on the speed? When you access the help from the network drive the TOC and Index appear quickly, but when you access it from the webserver there is the 5 second delay.
Kate

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 06, 2007 Feb 06, 2007

Copy link to clipboard

Copied

Kate

Try again with the link I sent you. Last night I trashed some smaller projects in the merge and also trashed one of the 4,000 topic projects. It did improve things but I think you will still find it too slow.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 06, 2007 Feb 06, 2007

Copy link to clipboard

Copied

Hi Peter,
That is better but there is still a delay. I think it comes down to the fact that every time the help is called, it uses Javascript to sort through all of the output files of all of the subprojects to construct the index and TOC.
It would be good if Robohelp had the option to do this once after you've published. Then the files would be ready users to download when they access the help, rather than Javascript creating them on the fly.
Thanks for trying,
Kate

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Community Expert ,
Feb 06, 2007 Feb 06, 2007

Copy link to clipboard

Copied

Yes that is an option that I will be putting forward to Adobe. Whilst the idea of the merge being created on the fly is good and in most scenarios it works well, there are some setups, such as yours, where a different approach is needed.

Help others by clicking Correct Answer if the question is answered. Found the answer elsewhere? Share it here. "Upvote" is for useful posts.

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Enthusiast ,
Feb 06, 2007 Feb 06, 2007

Copy link to clipboard

Copied

Kate,

Are you saying that the Web server doesn't access your files directly, but uses a network connection to bring them over as they are needed?

Or is the server actually pulling the files from the same storage device?

(All you experts, please forgive me if the is a doh-h-h-h question.)

Harvey

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
New Here ,
Feb 08, 2007 Feb 08, 2007

Copy link to clipboard

Copied

Hi Harvey,
It's difficult for me to say because the webserver is looked after by our webapps department who haven't replied. But I presume that IIS is pointing to a virtual directory which is the network drive.
I don't think this is the reason for the delay in appearance of the TOC and Index though, because there is no delay in the framework and the first topic appearing. Also, when Peter let me have a look at a merged webhelp project on his server, the same delay was apparent.
It seems that some kind of processing happens on the webserver that doesn't occur when you run it from a network, or local drive.
Kate

Votes

Translate

Translate

Report

Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
Resources
RoboHelp Documentation
Download Adobe RoboHelp