Michel_72 Posted April 20, 2022 Share Posted April 20, 2022 (edited) Hi, I am having issues since ugrading to 4.6.12.1. When posting new messages sometimes it's instant, sometimes it takes somewhere from 5 to 16 seconds. Since I also upgraded the OS (Debian 11 bullseye, as I do every month) I can not be 100% sure it's the Invision community upgrade. I have checked all /var/log/* for errors, enabled the mysql slow query log, but nothing suspicious. Anobody having similar issues, or maybe someone has some pointers on what to check next? Cheers, Michel Edited April 20, 2022 by Michel_72 Link to comment Share on other sites More sharing options...
Jim M Posted April 20, 2022 Share Posted April 20, 2022 Are these forums or topics where there are a lot of followers? If so, it could be your email connection is slow in sending these out. That would be something worth investigating. Link to comment Share on other sites More sharing options...
Michel_72 Posted April 20, 2022 Author Share Posted April 20, 2022 (edited) Yes, there could be a lot of followers. But why does to e-mail connection hold up (new) posts? Ar the e-mail notifications not being handled by a cron job? When editing the newly posted message that is instant. I'm trying to understand why this happens all of a sudden. The mailserver is unchanged. Edited April 20, 2022 by Michel_72 Link to comment Share on other sites More sharing options...
Michel_72 Posted April 20, 2022 Author Share Posted April 20, 2022 (edited) In this specific topic I was testing there are 6 followers. But I have also been testing in a topic that only has 1 follower and in there I am getting the same irregular delays. Wat mis je op sat4all? (graag reageren) - Pagina 7 - Off topic - Sat4all - Alles over Satelliet TV, Ziggo en Telenet! As far as I can see there are no significant delays there: Apr 20 20:00:02 ####### postfix/local[2155]: 8D75F807A2: to=<##########>, orig_to=<#####>, relay=local, delay=0.05, delays=0.03/0.01/0/0.01, dsn=2.0.0, status=sent (delivered to command: procmail -a "$EXTENSION") Apr 20 2 Edited April 20, 2022 by Michel_72 Link to comment Share on other sites More sharing options...
Jim M Posted April 20, 2022 Share Posted April 20, 2022 The follow notification are sent instantaneous so would not be handled by a background task. If the smaller follower count topic is faster than this would not be related. You would need to continue to investigate your server for an issue, I'm afraid. Link to comment Share on other sites More sharing options...
Michel_72 Posted April 20, 2022 Author Share Posted April 20, 2022 (edited) I am starting to think you may have a point. 😉 I used a 13 follower topic now which was slow most of the time. Then switched the email setting back from smtp to php and posting was then fast every time I tested. smtp is an external (TLS) mailserver, within the same network which is quit fast. There are 2 things I can wrap my head around. The mailserver is fast when trying it from the command line on the server running IPS. So why does this hold up posting. This mailserver was in use before the update as well without any issues. Why is IPS sending the email instant and does posting a message rely on a blazing fast smtp server? I would rather have this done by the cron running every minute so It will be a background proces. Edited April 20, 2022 by Michel_72 Link to comment Share on other sites More sharing options...
opentype Posted April 20, 2022 Share Posted April 20, 2022 You might not have noticed it before and now you are connecting it with the update, but it has always been this way when emails are set to use SMTP. I agree that it should always use a background task, but that is better posted in the feedback forum. Link to comment Share on other sites More sharing options...
Marc Stridgen Posted April 21, 2022 Share Posted April 21, 2022 We send notifications instantly only when there are a small amount. Once there are a large number, it will send them as a background task. Please feel free to suggest this if you want to see them always pushed to a background task, however it has to be noted that all you would be doing there is moving the issue. I understand it would then mean at least the post goes through, so it could mean you end up with a backlog of tasks, and things are not running behind those items, leading to other issues on the software. So the answer to the question really isnt moving the problem to run elsewhere. Its resolving the problem itself, which in this case is on the email server side of things Link to comment Share on other sites More sharing options...
Solution Michel_72 Posted April 21, 2022 Author Solution Share Posted April 21, 2022 (edited) Hi, I now 'fixed' the problem by configuring the local postfix server to relay via my external mailserver, so the mail will be delivered instantly to the local mailqueue and then relayed 'slowly' to the external smtp server. This will not speedup delivery, but does 'fix' this issue. Edited April 21, 2022 by Michel_72 Link to comment Share on other sites More sharing options...
Marc Stridgen Posted April 21, 2022 Share Posted April 21, 2022 Glad you have a solution to your problem there Link to comment Share on other sites More sharing options...
Michel_72 Posted April 21, 2022 Author Share Posted April 21, 2022 After rethinking this you might be right there is no optimal solution for this and the issue can be mitigated by queuing the e-mail as outlined above. So I'd like to redraw my feature request 😉 Ibai and Marc Stridgen 2 Link to comment Share on other sites More sharing options...
Recommended Posts