No, it's working fine with the other SMTP provider, so I guess it is still sending the notification emails somehow for those who subscribed while they have permission, because when I posted a test discussion and removed it as soon as it appeared, there was a user already viewing it (I saw it in the analytics Realtime console)
And that's why I asked how to see who has subscribed to the advanced notifications.
Oh, I thought it was part of the Preferences column in the GDN_User table and then it would be hard to find out. But it is in GDN_UserMeta and the Name column should start with Preferences.Email.NewDiscussion...
But You should focus and solving that Amazon problem.
Yes, that's my main focus from now on because amazon ses is what I'll be using to send the outgoing emails. I'll try to use a different amazon SES smtp server location and see if that works.
Here is the result after using a different Amazon SES SMTP server location-
I changed the server location to "US East (N. Virginia)" and it reduced the posting time to 7-8 seconds from 15-16 seconds. So it's definitely the server location.
This solution may solve the problem-
It's my understanding that the posting process is working like this-
I press the Post Button => Vanilla saves the post and does other necessary things to prepare the post => Vanilla Sends the notifications and emails => And finally, we see the discussion.
If the last two processes could be swapped, then the slow smtp response problem might be solved-
So it should work like this after changing the order-
I press the Post Button => Vanilla saves the post and do other necessary things to prepare the post => Vanilla posts the discussion => Vanilla adds the notifications and emails to a queue and then sends them after posting.
I'm not a developer, so please don't laugh if it sounds funny, LOL 😄
No, the idea is good. But the process behind all that, if you look at it more abstract, is like this:
Server gets a request
Server does what ever is needed to handle request
Server sends response
The problem is that each step is required to wait until the previous step is finished ("synchronous"). The last step will always be sending the response.
You might be able to mess around to work around that, but from my perspective there are only two clean solutions. One is using an asynchronous PHP framework/extension, which would require some serious design changes.
The other would be using a message queue or micro services: sending mails will always take way longer than simply create an "external" task for it (by using some external interface or directly writing tasks to the database.
Message queues will be stuffed with tasks and there are workers which run on those queues. So you must have a) a service which is running on the server which is capable of receiving such tasks (RabbitMQ comes to my mind here) and b) a service which fetches tasks from that queue and processes them (the hip word for that would be "micro service" I guess).
But normally sending mails via SMTP really shouldn't be slowing you down on small forums. There must be something else wrong. And since you already experienced a difference between some test SMTP connection and your Amazon SES SMTP, you might still not be happy with the Amazon performance
I'm a complete noob for all this technical stuff, but both the clean ways make sense, and it would be nice to see if any of these is implemented in the future.
And I don't know what's the definition of a small forum, but currently, there are 2217 users and 565 discussions on my forum, and I think it's a small forum if not micro 😉
And yes, I'm still not satisfied with the amazon SMTP performance, the other SMTP is working great, but I have no idea what should I do now to find out the problem.
Comments
Also the same with another SMTP provider?
No, it's working fine with the other SMTP provider, so I guess it is still sending the notification emails somehow for those who subscribed while they have permission, because when I posted a test discussion and removed it as soon as it appeared, there was a user already viewing it (I saw it in the analytics Realtime console)
And that's why I asked how to see who has subscribed to the advanced notifications.
Oh, I thought it was part of the Preferences column in the GDN_User table and then it would be hard to find out. But it is in GDN_UserMeta and the Name column should start with Preferences.Email.NewDiscussion...
But You should focus and solving that Amazon problem.
Yes, that's my main focus from now on because amazon ses is what I'll be using to send the outgoing emails. I'll try to use a different amazon SES smtp server location and see if that works.
I'll post the result here after testing it.
Thank you so much for your help.
Kind Regards
Hello,
Here is the result after using a different Amazon SES SMTP server location-
I changed the server location to "US East (N. Virginia)" and it reduced the posting time to 7-8 seconds from 15-16 seconds. So it's definitely the server location.
This solution may solve the problem-
It's my understanding that the posting process is working like this-
I press the Post Button => Vanilla saves the post and does other necessary things to prepare the post => Vanilla Sends the notifications and emails => And finally, we see the discussion.
If the last two processes could be swapped, then the slow smtp response problem might be solved-
So it should work like this after changing the order-
I press the Post Button => Vanilla saves the post and do other necessary things to prepare the post => Vanilla posts the discussion => Vanilla adds the notifications and emails to a queue and then sends them after posting.
I'm not a developer, so please don't laugh if it sounds funny, LOL 😄
Kind Regards
No, the idea is good. But the process behind all that, if you look at it more abstract, is like this:
The problem is that each step is required to wait until the previous step is finished ("synchronous"). The last step will always be sending the response.
You might be able to mess around to work around that, but from my perspective there are only two clean solutions. One is using an asynchronous PHP framework/extension, which would require some serious design changes.
The other would be using a message queue or micro services: sending mails will always take way longer than simply create an "external" task for it (by using some external interface or directly writing tasks to the database.
Message queues will be stuffed with tasks and there are workers which run on those queues. So you must have a) a service which is running on the server which is capable of receiving such tasks (RabbitMQ comes to my mind here) and b) a service which fetches tasks from that queue and processes them (the hip word for that would be "micro service" I guess).
But normally sending mails via SMTP really shouldn't be slowing you down on small forums. There must be something else wrong. And since you already experienced a difference between some test SMTP connection and your Amazon SES SMTP, you might still not be happy with the Amazon performance
I'm a complete noob for all this technical stuff, but both the clean ways make sense, and it would be nice to see if any of these is implemented in the future.
And I don't know what's the definition of a small forum, but currently, there are 2217 users and 565 discussions on my forum, and I think it's a small forum if not micro 😉
And yes, I'm still not satisfied with the amazon SMTP performance, the other SMTP is working great, but I have no idea what should I do now to find out the problem.
Thank you so much for all your help.
Kind Regards