The odd part I found while troubleshooting is that the logo is accessed once for live review, but three times for the save function. Does this mean that something is going wrong during save and the system has to retry several times?
This test is run on a test quote with just one line item “test” which results in a single page PDF.
I was trying to get snappdf to work, thinking this should provide the fastest / best performance. But at I am happy with 8x performance improvement.
At this point I’ll try contacting the snappdf team / forum and see what advice they could provide. I’ll update the tread if I’ll find the root cause of issue with my setup & snappdf slowdown.
@hillel, Thank you for the link. I guess searching for documentation mainly points to rev 4. laravel Supervisor for the queue management sounds interesting, though it seems I can do the same thing with a simpler cron. I’ll have to look further into the advantage of supervisor vs cron for the queue management and update this thread with the results.
You may want to try settings in your .env LOCAL_DOWNLOAD=true
and see if that improves snappdf, i think it may be a DNS issue if it is taking that long, it really shouldn’t take more than a second or two to generate the PDF end to end.
@david, thanks LOCAL_DOWNLOAD brought the requests for the logo from 3 down to 1. Otherwise, it didn’t seem to speed up the hosted or snappdf generation.
At this point I’m pretty sure the issue lies with snappdf config. I’ll try to troubleshoot it further tomorrow and upgrade the tread with my findings.
Thank you @david and @hillel again for the weekend support and advice. Above and beyond, both of you.
P.S. For those who run into a similar 3 request question, I found that I had to run php7.4 artisan optimize in appropriate directory in order for LOCAL_DOWNLOAD change to the.env file for effect to activate. Saving and rebooting the system along was seemingly not enough.
Update: I found a permissions issue with the folder snappdf would download the crome to. IT was owned by the user I use to connect, not the www-data user that invoice ninja operates under. Seems, when installing snappdf, it is a good idea to run the composer commands as sudo -u www-data user, otherwise check the permissions / ownership of the following folder:
/usr/share/nginx/invoiceninja/vendor/beganovich/snappdf/versions/
After the change snappdf seems to be as fast as hosted pdf generation.
Disabling LOCAL_DOWNLOAD parameter, resulted in the three requests for logo during save, even with snappdf operating at the optimal speed. This confirms that the number of requests does not indicate failure or retries by the pdf generator.
Thank you again, @david and @hillel for your assistance.
Another update, I finally figured out what was going wrong with QUEUE system, in my case a second (hidden) sync config (from the sample .env I’ve customized) was overriding the database QUEUE I’ve tried to use:
I’ve learned to save often, as sometimes connectivity to the server is lost and any active edits are lost with it. I wish there was an easy way to get back old live previews to copy and paste the lost edits.