IIS Application performance degrade after populating large document

Aspose.Words Product Family
1

Hi guys,

I upgraded Aspose word library from 20.4 to 23.1.

I have a legacy asp.net webform application (.net 4.8) that populates a large document.
The document is populated by merging multiple sub documents.

After upgrading to 23.1, I noticed there’s very noticeable performance degrade in the application after populating the large document. For example, there is a web form page that takes 1-2 seconds to load. After the large document generated, the same pages takes 6-8 seconds load. During 6-8 seconds, I can see CPU hitting 50% (dual core server, meaning 1 core is running very high)

In the same code base, I swapped 23.1 to 20.4. I tested the same scenario again and confirmed the performance degrading is not happening.

I also tested the same scenario with 23.9 which is the latest. I confirmed performance degrading still happens.

The source code that generates the large document is very complicate. I am working on making the simplified sample code that can replicate the issue but it could take a while.

I wonder if you are aware of any similar issues?

2

@sentientsoft Unfortunately, it is difficult to say what causes the problem on your side. There was a performance degradation while using Document.AppenDocument method in 23.8, which was quickly fixed in 23.9 version. So if possible please create a simple console application that will allow us to reproduce the problem on our side. We will investigate the issue and provide you more information.

3

Hi Alexey,

I’ve managed to find out which version of Aspose Word started having the performance issue.
It’s 21.12

With same code base, up to 21.11, I don’t see the performance degrading issue after the large document populated.
After 21.12, I can see the performance issue. (Also tested with 22.1)

As I mentioned above, it would take some time for us to create a sample code to reproduce the bug. Would you be able to look into the change logs between 21.11 and 21.12? See whether there are changes that could cause the issue?

Regards,

4

@sentientsoft Unfortunately, I do not see any changes that might cause the performance degradation. Also, there were no complains from other customers regarding this problem since then. So we will wait for a code that will allow us to reproduce the problem from you and then investigate the problem on our side.

5

Hi Alex,

I’ve narrowed it down where the issue is coming from.
Long story short, it was related how we add custom font folder reference to the document.

I found a piece of code (added back in 2014-15) that links custom font folder in our source code, which looks very similar to the sample code in below link.
https://docs.aspose.com/words/net/manipulating-and-substitution-truetype-fonts/#font-availability-and-substitution

The issue was the code is embedded in the constructor of a custom class which inherits Aspose.Word.Document, which eventually runs on every single document object creation and keeps adding the same font folder reference into FontSetting over and over. This is not ideal. I tweaked code and the issue went away ish…

AsposePerformanceIssue.7z (5.3 KB)

I’ve attached a solution file. The solution has got 8 console projects which runs with different versions of Aspose Word library.

  • Performance_Aspose21_11 → This demonstrates 21.11 runs just fine with code before fix
  • Performance_Aspose21_12 → This demonstrates 21.12 having big performance impact before fix
  • Performance_Aspose23_09 → This demonstrates 23.9 having same performance impact before fix
  • Performance_Aspose21_12_WithFixedCode - This demonstrates 21.12 with fix no longer having performance issue
  • Performance_Aspose23_09_WithFixedCode - Better with fix but somewhat slower than 21.12
  • SimpleObjectCreation_Aspose21_11 - This shows object creation speed with 21.11
  • SimpleObjectCreation_Aspose21_12 - This shows object creation speed with 21.12
  • SimpleObjectCreation_Aspose23_09 - This shows object creation speed with 23.9, considerably slower than 21.11 and 21.12

It would be great if you could have a look the code and confirm & explain

  • I understood the custom font folder reference just needs to be added once into FontSetting in application life cycle (as long as all docs using the same fonts). Fixed code checks whether the folder is already added or not and if added, it skips logic. Would it be the right approach? Or perhaps just add font reference at the application start event and don’t bother adding font reference at the document level.

  • Just curious to find out why 21.12 and onward suddenly shows huge performance degrade. I understand adding the same font reference over and over isn’t great but until 21.11, it worked fine.

  • 23.9 shows object creation performance isn’t good as 21.x versions. We have some scenarios where we create xxxx number of documents and merge them into one, depending on how many items user chose. It’s not a major and 23.x performance is kind of acceptable for now but can this be improved?

  • I can see in the document, it says FontSettings is shared. Perhaps you could add a bit more guideline that the code could be just one off thing to run at the application level, just to avoid people making the same mistake like ours.

Regards,

6

@sentientsoft I have logged two issues in our defect tracking system

  • WORDSNET-26002 - Performance issue while adding custom fonts folder
  • WORDSNET-26003 - Performance issue while simple Document object creation in 23.9 version.

Our development team will deeply investigate the reasons of performance degradation and we will provide you more information or probably a fix. Please accept our apologies for your inconvenience.

Since you are using FontSettings.DefaultInstance it is enough to add custom font folder only once on application start, it is not required to do this on every object creation. Alternatively you can create a new FontSettings instance and reuse it for every document you create.

7

Thanks for the update Alexey :slight_smile:

1 Like
8

@sentientsoft We have completed analyzing WORDSNET-26002 and decided to close it as Not a Bug. The code below recalculates global font cache. Normally, this should be done once during the application’s lifecycle.

FontSettings.DefaultInstance.SetFontsSources(newFontSources);

Adding font reference at the application start event is correct behavior. Lazy initialization can be recommended also.

The issue WORDSNET-26003 is currently in analysis. It looks like performance degradation upon creation new instance of Document is causes by changes in Aspose.Words obfuscation settings. We will keep investigating the issue and let you know once there are any news or fix.

9

Thanks for the update. Yes I agree WORDSNET-26002 can be resolved by better coding practice.
I will wait for further update about 26003. :slight_smile:

1 Like
10

Hi Alexey

I can see 26003 issue is closed. Could you provide us some update?

Regards,

11

@sentientsoft Yes, the issue is already resolved in the current codebase. The fix will be included into the next 23.11 version of Aspose.Words. We will be sure to let you know once it is released.

12

The issues you have found earlier (filed as WORDSNET-26003,WORDSNET-26002) have been fixed in this Aspose.Words for .NET 23.11 update also available on NuGet.