This content has been marked as final. Show 25 replies
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.
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.
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.
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.
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.
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.
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?
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.
Please email me offline via my website.
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.
I routinely make these fixes:
It's missing a </body> tag before </html>
Same as above
Has </head> not followed by <body>. Either move </head> down to nearly the end, or insert <body> and then near the end, insert </body>
Has head and body sections with a block of scripts between them. Should be in one or the other.
Has no proper <body> tag.
Also have a look at the launch file,
After the </head> there are scripts not enclosed in a head or body section. I move </head> down, just before the framesets.
No <head> ... </head> tags before and after the block of scripts.
whskin_frmset01.htm and ...10.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:
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
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?
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.
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.
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.
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.
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.
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).
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?
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.
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.
Thanks for trying,
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.
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.)
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.
Oddly, my response time is better via the Intranet.
I publish to a network drive by copying files (not FTP).
As far as I know, those are the files I'm looking at when I use the Intranet URL.
When I point the browser to the network directory path/filename, everything is much, much slower than when I use the URL.
The frames and launch topic appear fast., not much difference (Internet is faster).
I should hasten to say, however, that the merged TOC, Index and Search data do take more time than I would like to see. It is not instantaneous. However, it's worse using the path/filename address.
This brings me back to the issue of network traffic. If it's a quiet time, the path/filename load can look almost as fast as on the PC. I still would continue to ask the IT guys how they move data around and how well response time is being optimized in hardware/firmware/software.