long sending time when big recipientlist
mangopulp opened this issue · comments
First of all - very big thanks for this very nice extension! All thumbs up! The Issue I have with this extension is at a very special level and is for optimization proposal from my side.
I used a recipientlist with around 1700 recipients. When I startet sending, it took around 7h until each mail was send. Analysing the code, shows that the method injectLinksSpy() in class Ecodev\Newsletter\Mailer needs around 15 sec. to modify all links in the newsletter and this method is called for each recipient. Although the method injectOpenSpy() in the same Class consumes a little time which only is noticeable when it comes to bigger recipient lists. I think it would be a more powerful approach when this two methods are called before sending and the modified Newsletter gets cached, so the methods don't need to be called again while sending the newsletter to each recipient. Then at this point it would only ne necessary to replace the markers with the personal data. This approach should speed up sending a lot.
15 sec. for a single email is way longer than it should be. There is something unusual going on...
- What version of Newsletter ?
- What storage engine for each newsletter tables in your DB ?
- Approximately how many links per email ?
- How many records in your
tx_newsletter_domain_model_linktable ?
Hi PowerKiKi,
here the missing information
TYPO3 = 7.6.23
Newsletter = 3.2.0
Storage Engine = InnoDB
Links = 14
tx_newsletter_domain_model_link = 4025 records
Thanks for your quick help!
That seems to be very low numbers of records for such a long delay to send a single email. Were you able to identify what part of getLinkAuthCode() is taking such a long time ? Would it be the SELECT query ? or the INSERT query ? or something further ? Could it be in UriBuilder::buildFrontendUri() ?
I will take a closer look to get more information what's the reason for the long delay. Will be back soon.
So, I could get some more information where the delay comes from. As you suspected the part "UriBuilder::buildFrontendUri" consumes a little more then 1 sec. per link. The newsletter has 14 links so in the end it takes 15 sec. per mail
I suggest you remove realurl, or whatever extension you use for nice url, and try again. This will surely lead to instant UriBuilder::buildFrontendUri(). It if it does, then you know for sure that the bug is not directly related to Newsletter, but rather a misconfiguration of realurl.
I'm closing because this is most likely not a bug in Newsletter. But you can keep sharing your progress if you feel like it.
Yes - realurl is the time consuming part in that process. Without realurl it's like Speedy Gonzales and Road Runner together. And you think it's a misconfiguration of realurl? So with a correct configured realurl it although should be much faster?
Thank you so much for your help!
@mangopulp you might be interested to know that Newsletter 3.3.0 was just released and includes a huge speed boost for sending emails with RealURL. See commits mentioned above for details.
@PowerKiKi both thumbs up. I upgraded to 3.3.0 and in run's perfect! Big Thanks!!!