-
Notifications
You must be signed in to change notification settings - Fork 556
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to improve tps in multithreading #340
Comments
@shiyong-1224 Sorry, but I cannot reproduce this issue. When I generate PDFs in parallel threads, they work fast. More threads -> faster generation. |
@asolntsev Thanks for your Reply,here is a sample project https://github.com/shiyong-1224/test-pdf.git |
@shiyong-1224 Thank you for sharing the project, but ... again, how I could easily reproduce the problem?
Is it possible that the problem is caused by Spring/Tomcat/servlets/etc... ? Anyway, I've found few candidates for performance improvement in FlyingSaucer. I will release these improvements soon, but not sure it entirely fixes your problem. |
@asolntsev Sorry I didn't describe it clearly.
I changed corePoolSize from 2 to 8 to 16, and use Jmeter(uploaded a script) to make full use of threads, Then I saw the time consumed increasing by num of threads. |
My profiler shows that some remarkable % of CPU is spent on generating this string: (" " + c + " "). Now we check for CSS class without generating the new string. The code is longer, but faster.
Now we check the "lang" attribute without calling `String.split` method which generates new strings.
in some places, I replaced them with `synchronizedMap()` or `ConcurrentHashMap`. Not 100% sure nothing gets broken. :) But at least all tests are still green.
My profiler shows that `nsh.getClass((Element) e)` consumes quite a remarkable percentage of total CPU time. So I hope caching these value could improve performance (though, my profiler doesn't show it :) ).
My profiler shows that some remarkable % of CPU is spent on generating this string: (" " + c + " "). Now we check for CSS class without generating the new string. The code is longer, but faster.
Now we check the "lang" attribute without calling `String.split` method which generates new strings.
in some places, I replaced them with `synchronizedMap()` or `ConcurrentHashMap`. Not 100% sure nothing gets broken. :) But at least all tests are still green.
My profiler shows that `nsh.getClass((Element) e)` consumes quite a remarkable percentage of total CPU time. So I hope caching these value could improve performance (though, my profiler doesn't show it :) ).
…in indexOf()calls" A quick-fix is suggested to replace such string literals with equivalent character literals, gaining some performance enhancement.
…in indexOf()calls" A quick-fix is suggested to replace such string literals with equivalent character literals, gaining some performance enhancement.
@shiyong-1224 Hi. Can you check if the problem was fixed in FlyingSaucer 9.9.0? |
I am using a ThreadPoolExecutor to execute a pdf rendering task (flying-saucer-pdf:9.1.22 Java 11), here is the main code of each task:
It performs best when I set corePoolSize = 2
As I increase the corePoolSize, the time consuming of 'layout' and 'createPDF' method increases and the tps decreases.
Even if I increased the CPU from 2 cores to 8 cores, it didn't help.
so I wonder if there is any resource contention or lock between threads, and how can I improve the tps of single machine
The text was updated successfully, but these errors were encountered: