New Incident with large subscribers - not done in background

[Artic6]

If you have a large number of subscribers after you update the incident to goto them all, the script does this live not in the background which means after you click the "new incident" button you get a very long pause while the script sends all the emails and the script them waits for all the emails to be sent.

Can this not be done in the background as I have had to increase the PHP script timeout to 800 seconds to see if that will allow all the messages to be sent ?

3 minutes 30 seconds in we have only sent 3760 messages out of 10,240 - what is worse is this also needs to send a component update then the incdient email

However I cannot have people waiting 20 minutes after clicking the "new incident" button to get the update all done, then another 20 minutes for each future update.

I have noticed you have large companys using this Cachet - if that is the case have they are repoted waiting upwards to 20 minutes to get a "single" update notification sent ?

[Artic6]

I set the PHP timeout to 800 seconds or 13.3 minutes and we send 10,201 messages (as it only uses one connection to send them)

However, in that time as we have to send the "component update" then the "incident email" to 10,201 subscribers which means a total of 20,402 messages - based on that a single incident update would take 30 minutes send.

[Artic6]

Can we use more than one SMTP session at a time - is that a variabel you can configure ?

[Artic6]

if #4400 was fixed in the actual code then this might work

[Artic6]

I’ve had to use different repository however background processing of emails would be appreciated

[shumbashi]

@Artic6 can you tell us which repository you used? I'm struggling with the email issues as well

[Artic6]

If you are having the problem with emails as I’ve described in this post, it doesn’t matter which branch or repository you use

I’ve even tried other custom ones, While this product might be open source, it’s got far too many floors for me to continue using it

The only response you ever get from cachet Is we’re putting all our time into version three - Which means they don’t really support the current live production version

I would also question on the public website list of companies that use it - There is no way all those companies don’t have the problems I’ve reported when sending to 11,000 employees

The companies showcase are far larger than the company I work for……

The way I said the incident should work is when you submit an incident, that should be published immediately, and then it sends the emails in the background

Currently it does it the other way round so if you’re sending it to a large User base the first 400 people when they click on the view incident will get a 404 because at that point it’s not actually made the incident live

To send to our 11,000 fuses are needed to increase the memory to 12GB And then the HP time out to 9400 seconds

The process still takes 96 minutes and doesn’t send to everybody……..

I have all started looking at paid alternatives that offer a proper support that isn’t we’re working on the next version, Which ironically seems to be nowhere near ready to release……

Regards,

Lee Croucher

📧: @.*** 🚦: http://a6n.co.uk

On Fri, 9 Aug 2024 at 10:51, Ahmed Shibani (Shumbashi) < @.***> wrote:

@Artic6 https://github.com/Artic6 can you tell us which repository you used? I'm struggling with the email issues as well

— Reply to this email directly, view it on GitHub https://github.com/cachethq/cachet/issues/4410#issuecomment-2277578305, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAD7S77OJ4MIR6CZFB4JSLDZQSGJ5AVCNFSM6AAAAABKM3RPTKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENZXGU3TQMZQGU . You are receiving this because you were mentioned.Message ID: @.***>