Making WebHelp load faster?

[Valiant]

We have a fairly complex WebHelp project . There is one main project with 430 subprojects nested under it, some up to four layers deep. The entire project is generated on Flare 3.1 and we are enabling feedback using Feedback Server. Once this project is released, we plan to move to Flare 4.x. Currently, we are only opening WebHelp to our fellow employees from an internal XP box running IIS which I know isn't the best machine for the job.

Previously we noticed the Search and Index functions were slow because we had not enabled the "Pre-merge" feature for the Index and Search files in the main target. I noticed from the IIS logs that it crawled through every project for Search or Index when the pre-merge was not enabled. Once pre-merge was enabled, Search and Index work quite well in the large project.

However, there is still a significant delay when first opening the project as the IIS log shows it must crawl through every project for the Glossary and the XML files. Is there any way to speed this up? It would be nice if they could pre-merge as well especially once we go live to our general user base. I suspect what is slow on an in-house XP IIS box won't serve any faster once posted on our website.

[Madcap Guru]

Flare output will be slow for the first user who access its, But after that it will be quicker for everyone else, its just the very first user that should have that problem,

With that many project, I would recommend that you host it on a decidated webserver.

[Valiant]

It's not just the first user. Every user sees the delay. Once the page has loaded, if you hit refresh the delay repeats as the page refreshes.

[Madcap Guru]

I would open a support ticket then, also if you try it locally does the delay occur? Could be an issue with your webserver.

https://www.madcapsoftware.com/support/contact.aspx

[ErimuHarada]

When a WebHelp file is opened, the script in it acccesses a project xml file in all subprojects.
There are five or more frames in a help file and every frame accesses xml files.
A browser reads 430x5=1200 files when you open your mega-project.
This is unavoidable if you don't pre-merge subprojects.
(If you want to look into the cause, you see MadCapToc.js.)

I think if MadCap improve this problem, they provide an asp file or something like it.

[ErimuHarada]

Sorry, I misunderstood.
only indexes and search databases can be pre-merged.
If MadCap provide the feature which pre-merge subproject xml files, this will be solved.
I still think there's no workaround now.

[Valiant]

This has gotten substantially worse. We have now moved up to Flare 4.2 (briefly) and on to Flare 5.0. The delay when opening the project or returning to the home page is significant now that the project is updated and generated under 5.0.

[Valiant]

We now have an issue open with support. Monitoring the IIS log when the project is generated under Flare 5.0 has multiple GETS for the same file, some up to 17 times per file. We fell back to Flare 4.2 to generate and the same project has some multiple GETS for the same file, but no more than 3 times per file.

The time with the Flare 4.2 generated project could be faster, but the Flare 5.0 generated project takes 3 times as long to load.

[Skooter]

I too have an issue open with support. Published ebhelp takes 40 seconds to load (despite "Done" being displayed in lower left of the browser!). After building a test project and creating webhelp output with just 2 simple topics I still got the same 40 second delay.

[RamonS]

How fast is your client? Keep in mind that most of the dynamics in WebHelp come from JavaScript. If you have a browser that as a slow JavaScript engine (like IE, FF3.0) then it takes forever. JavaScript is the main reason for any web page to be slow. It also depends on which PC you use, some underpowered netbook or an old server box may take longer to execute JavaScript.
Would be nice to have a WebHelp that is based on platform independent server side scripts as much as possible. Server side scripting is typically faster than client side scripting, or at least it is consistent in performance for all users.

[Skooter]

My laptop is probably not the fastest (DELL Precision M4300 Intel(R) Core 2 Duo CPU T7500@ 2.20GHz 789 MHz - whatever my ssytem properties mean !) Would be great if when loading Webhelp I could at least display a 'Loading please wait..." message - that way users wouldn't give the webhelp up for dead!

[RamonS]

The sad thing is...for the "Loading - please wait!" message you'd again need a script. Is it users who have to wait or is it so far you with your laptop who has to wait?

[Valiant]

If waiting for WebHelp to load is an issue, try dropping back to Flare 4.2 instead of building with Flare 5.0. We are still waiting on a resolution for increased load times on Flare 5.0 generated projects. It is 3x as long to load the Flare 5.0 gnerated project as the Flare 4.2 generated project.

[Skooter]

The sad thing is...for the "Loading - please wait!" message you'd again need a script. Is it users who have to wait or is it so far you with your laptop who has to wait?

Mostly me - although recently I noticed it is loading okay if I launch the webhelp, say, first thing in the morning - seems like my laptop looses memory/processing speed progressively during the course of the day as I use various applications - but I also had a few complaints from users who said the webhelp was slow to load - so the issue is how to guarantee a reasonable load time for all users - or at least have a good excuse as to why it may be slow to load.

[RamonS]

Slow is always a very relative term. In your case, you should be back to morning performance after a reboot. If that is the case, then some application you run has a massive memory leak. Going down like this within a day is in my QA book a high error on the brink of getting critical. Keep in mind that only because WebHelp loads slowly or not at all it does not necessarily have anything to do with the WebHelp.

[stealth94rt]

I am also noticing the same "slow" load times that other users are complaining about in the above posts. We have several Webhelp projects that were previously deployed from Robohelp. We've converted these over to Flare 5.0 and the Webhelp load time has gone from ~5 seconds to ~40 seconds. That said, I tested the Flare 5 project load time in IE 8 and Firefox 3.5.2 -- the load time in Firefox is much faster (less than 10 seconds).

Question: has Madcap acknowledged the Webhelp load time as a bug? If so, have they given an estimated time for a fix?

Thanks.

[Valiant]

We submitted this to Madcap support at the end of June, providing them with the IIS logs that show the longer times loading a Flare 5.0 generated project. Right now, we are editing in Flare 5.0 and then going back to Flare 4.2 to build.

I'm really hoping a resolution to this issue and two others that we've reported are coming soon, but I've never heard any updates on when to expect changes.

[stealth94rt]

I have gone back and regen'd my projects in v4.2. Unfortunately, that version does not have the Previous/Next buttons on the Webhelp toolbar. However, I felt that missing those was not as bad as an incredibly slow load time. Hopefully, they'll get v5 fixed SOON!

[KevinDAmery]

Standard MVP spiel:

If you run into a problem, submit a bug report, even if you know that someone else has done so already. There are two reasons for this:

1 - Madcap has told us that the more people submit reports about something, the higher priority it is given.
2 - It's possible that you have some information that other submitters didn't include, which may help Madcap find and solve the issue faster or more thoroughly.

You can submit bug reports and enhancement requests here:
http://www.madcapsoftware.com/bugs/submit.aspx

[stealth94rt]

I submitted a bug report on this issue. Now waiting for a follow-up from Madcap support.

[Landy]

The last post in this thread was over 2 years ago.
Has there been any update on the issue from MadCap or has anyone had responses to issue raised?

This particular issue is causing me some grief as the performance is seen by some as unacceptable.
I did raise a bug report earlier in the year and it is time to follow that up again...

[RamonS]

When you say by some, is there anything special about these some? Such as 256 MB RAM Windows XP boxes with an old P3 processor connecting via dial-up? Also, which browser do these some use and what else are they downloading at the same time?

[Valiant]

I'll give my update, since I posted the original issue and the problem was never addressed within Flare. We basically redesigned the layout of our project to live within the limitations of the slower opening process. By monitoring the IIS logs, we were able to see that the "newer" versions of Flare (more details in original post) generated projects where we saw multiple "gets" of the same files (multiple as in 10-12 times). So here's what we ended up doing, which sped the initial project opening up but makes the search and navigation more cumbersome for the user:

Original Structure:
Main Project => many child projects => many grandchild projects => some great grandchild projects

Revised Structure:
Main Project => Other projects independently generated and manually placed under the main project => child projects => some grandchild projects

So rather than one long delay at the beginning, the client now sees a smaller delay opening the main project, then a delay again opening any project under the main one. It isn’t an optimal solution but one we’ve had to live with due to lack of progress on the bug we opened. It’s not the only bug we ran into using the subprojects structure. I think though Flare supports this feature it isn’t a high priority since they figure many users must not use subprojects.

With each new version of Flare, when I've inquired about the issue I've been told it would be considered for the "next" release.

[Landy]

Thanks for the update Valiant.

OK at this point it really comes down to one specific issue for me, and that is the way that the CSH works. I can probably accept the 5, 10, or 15 second load time upon initial load, but what I have a big problem with is the fact that this same delay happens EVERY time that a CSH call is made. The entire Webhelp help system reloads itself every time you use CSH.

What it should do is simply locate and display the appropriate topic almost instantly without reloading the entire system. If this change could be made to the way that Webhelp CSH works, then it would make the entire help load speed issue pretty much go away.

Can someone from MadCap please explain how and why CSH works this way, and also technically assess what could be done to change it as suggested above. Finally, are there plans to change the way this works on the Flare development roadmap?

[LTinker68]

Can someone from MadCap please explain how and why CSH works this way, and also technically assess what could be done to change it as suggested above. Finally, are there plans to change the way this works on the Flare development roadmap?

This is a peer-to-peer forum. Although MadCap Support occasionally checks in, it's not their primary method of communication. You might want to contact them directly to get the answers.