3 ms·
I am using this in prodution instead of Dink2PDF since recently, generating 30K PDF daily (in tens of minutes, with multiple threads). It works great, highly re
by majkinetor 4y ago
I am using this in prodution instead of Dink2PDF since recently, generating 30K PDF daily (in tens of minutes, with multiple threads). It works great, highly recommended.
Dink2PDF was crashing monthly in this scenario due to internal unmanaged memory problem so we had to replace it. Not to mention, HTML to PDF libraries are insecure, and dink is no exception - you can execute arbitrary code on the server. Not to mention that you need to have full browser engine in your app...
- yyyk 4y agoCrashing is a problem with wrappers for wkhtmltopdf library when they run concurrently (you need the right locks, some wrappers have this but not dink apparently?). However, process-based wkhtmltopdf wrappers are also available and don't have this problem at all (e.g. nreco. It's also not too difficult to create a wrapper for oneself).
- majkinetor 4y agoWe had very funky case - the crash happened couple of times per month only, with web app doing daily work via REST API producing very large collection of pdfs on single API request, each having from couple to 5k pages. It was very hard to troublehsoot and pinpoint memory corruption problem (took us several months, one doesn't expect this in C# app). Finally we switched to QuestPDF. Surprisingly, performance was exactly the same as with dink (which is surprising); I see in recent changelog 50% speed up on textual PDFs so this might be a game changer (TBH performance is great even now). BTW, we used dink for half decade in public web apps with millions of users. Dink was used to create PDF reports and we never had a crash in that concurent scenario. However, when we started doing typical non-web multithreading this started to happen.