You are viewing limited content. For full access, please sign in.

Discussion

Discussion

Weblink - Performance Tuning

Version 11 WebLink
Updated June 18, 2024
posted on June 17, 2024

Does anyone have any specific details regarding performance tuning of Weblink?  We are experiencing a massive decrease in performance with Weblink image loading since upgrading our environment to latest version of the entire suite of Laserfiche products.  We upgrade the Server OS's to Windows Server 2022 Datacenter.

We are not seeing image load problems with the Web Client (AKA WebAccess).  It is disappointing to see such a decrease in performance form a product we are paying for unlimited license, and it can barely serve 1 client without problems.

0 0
replied on June 17, 2024

Do you have an explanation as to why the web client would be incredibly faster than the weblink interface.  We have both running on the same virtual machine and we notice weblink is much slower.

0 0
View 1 previous reply
replied on June 17, 2024 • Show version history

They're different codebases, but they shouldn't be wildly difference in performance. 

I have a test system with both Web Client (11.0.2102.205, a few updates back) and WebLink 11 Update 3 (11.0.2307.136, latest, same as you have) installed on the same server and connected to the same repository. It's a fairly speedy server that also hosts the repository on SSD storage, so look at these numbers in relative rather than absolute terms.

I tried opening the exact same two-page imaged TIFF document in each using a Incognito browser window with caching disabled:

  • WebLink: 2.17s
  • Web Client: 3.15s

Web Client has about twice the amount of page asset data to load and render than WebLink (4.5 MB vs 2.2 MB) so I'm not surprised to see it take a little longer without caching.
WebLink:

Web Client:

Hopefully that helps demonstrate that what you're experiencing is not normal. WebLink is usually the faster interface because it's lighter weight than the full Web Client. If WebLink is "much slower", there's likely an issue somewhere that needs to be addressed.

Outside of the .NET Framework Update that broke things for a whole bunch of customers that I mentioned in my other reply, I can't speculate what that issue could be.

If you could use assistance troubleshooting, I recommend opening a support case with your Solution Provider, who can open one with us if necessary. Please do rule out the .NET Framework update issue first if you can though.

0 0
replied on June 17, 2024

I took at look at your WebLink site, opened a few docs, and one thing that stood out to me in DevTools>Network were the /ThumbnailImageData.aspx calls that load the images in the left-hand thumbnail pane taking a while. it looks like these thumbnail calls may have to complete before the main image TileData.aspx ones. When I reloaded DocView pages with client-side caching still disabled, they loaded about twice as fast, suggesting server-side caching.

WebLink and Web Client will both use existing thumbnails from the repository if they are present, but will generate their own if necessary. I don't know if they share the same thumbnail generation code. 

You should check if Background Thumbnail Generation is enabled in your repository. I recommend enabling it if not. Otherwise, the web applications will have to generate them on the fly when documents are opened.

Though that may not be the whole story, it may help and certainly can't hurt.

0 0
replied on June 18, 2024

Thank you very much for the information.  I enabled the background generation of the thumbnails.  Anything we can do to increase the performance.  We were on weblink v.9 previously and it was noticeably faster.

0 0
replied on June 18, 2024

I'm not aware of any generic performance tuning enhancements for WebLink that would affect image loading specifically. You should run the PowerShell IIS settings optimization script I linked to in my other reply. That can help with initial WebLink site loading time by keeping the app pool loaded and stopping it from going idle.

WebLink 9 was released over a decade ago. "Why does something with 10 years of code changes seem to do some operations more slowly in my particular environment?" doesn't have one easy answer.

You've stated what seem to be two different issues though:

  • "massive decrease in performance with Weblink image loading"
    • Image loading was indeed somewhat slow, which is potentially due to WebLink having to first generate thumbnails on the fly, as described above. If this is a component, you should see at least somewhat increased image load performance once Background Thumbnail Generation has finished running on your repository content. That's not an instantaneous process so give it a few days and then re-test WebLink.
  • "it can barely serve 1 client without problems"
    • Have you observed specific issues with WebLink serving multiple clients? The image loading delays are unlikely to have anything to do with concurrency (unless the whole server CPU is getting bottlenecked on thumbnail generation tasks, which is extraordinarily unlikely).
    • When I was looking at your WebLink site the other day, I opened a few separate sessions and didn't personally see anything that suggested the site had issues serving multiple client sessions simultaneously. 

Have you compared the loading times of the same documents in WebLink vs Web Client in your environment, using browser DevTools with a fresh Incognito/InPrivate window and caching disabled? If not, please do so to get some objective data on the performance differences.

0 0
replied on June 17, 2024

Hi Nathan,

Since you mention "it can barely serve 1 client without problems", which I can assure you is not a systemic issue with WebLink 11 upgrades, I wonder if the system may be affected by this recent issue:

The May 14, 2024 Cumulative Update for .NET Framework May Cause Reliability Issues with the Laserfiche Web Client and Laserfiche WebLink.

Long story short, a recent non-security Microsoft .NET update broke some WebLink and Web Client deployments that causes rapid chain crashes of their IIS worker process. From the end user perspective, these rapid crashes can look like performance issues because the web app launches, tries to do something for the user, crashes, relaunches, then browser fires off retries for incomplete calls, then the process crashes again after maybe getting past loading the next tile, relaunches, crashes, and so on.

We have customers where both WebLink and Web Client are affected, only one, or none. We haven't figured out exactly what causes the issues yet (or at least all of the things - there may be multiple) but are actively working on it.

I would check if the issues only started occurring after the May 2024 .NET Framework Update was applied. If so, uninstall that update per the instructions.

You should also look at the event logs on the server with WebLink. Check Windows\Application, Windows\System, and the Applications & Services\Laserfiche\WebLink (Portal) logs for any Error or Warning messages that could correlate with attempting to (slowly) load an image. Specifically check for the error message mentioned in the Support Site article linked above, but there could be other relevant ones as well.

If it's not the .NET Framework Update issue, please open a support case. Being able to "barely serve 1 client without problems" strongly suggests there's some sort of issue going on that needs to be resolved before thinking about WebLink-specific performance tuning. 

That said, I do have a general IIS settings optimization PowerShell script that updates some defaults to make initial response times faster by "preloading" the web apps instead of waiting for the first request to come in. The script is named " iis-config-optimization-extended.ps1.txt" and you can find it here: https://answers.laserfiche.com/questions/193847/FormsInitial-Login-Slow#193889

1 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...