Please upgrade here. These earlier versions are no longer being updated and have security issues.
HackerOne users: Testing against this community violates our program's Terms of Service and will result in your bounty being denied.

~10 seconds delay posting conversations/messages (using Vanilla 2.6)

I just upgraded to latest 2.6 from 2.5.1. I cannot say if this was a problem in my 2.5.1 setup as the site is pretty new.

I notice that creating a new personal message (sending a POST to https://.com/messages/addmessage/) is taking 10-12 seconds before it receives a response. This is very similar to my recent thread where I found a workaround, but is not applicable in this case.

It was mentioned in that thread to look at MYSQL slow logs, which I do not have access to. Any other ideas to see what is going on or how to go about fixing?

Does anyone else see a 10-12 second delay when posting message with the 2.6 setup?

Comments

  • R_JR_J Admin

    I would also look at all your browser tools: watch out for JavaScript errors, take a look at the net log in your browser and maybe you can take a look at the access and error logs of your web server (even shared hosting providers often give you access to those)

    If your forum is new I'd guess there are not much entries in there and therefore the database wouldn't be the first thing I would think of.

    Is the delay is reproducable? Does it happen with a) all browser and b) all users c) and independent from the network that you are in?

    I would do two things:
    1. disable all plugins and switch back to default theme to see if it is Vanilla or a plugin that causes this behavior
    2. do a clean install on the same server and try to reproduce that misbehavior in order to find out if this is a server problem or a setup problem of your current forum

  • LincLinc Admin
    edited May 2018

    My first suggestion is of course to eliminate any addons or themes and see if the issue persists.

    The only time I've seen something like that is when a site is sending a tremendous amount of email triggered by the delayed action. Vanilla's email sending happens synchronously, so if you tried to, say, use it as a listserv for an email group, it starts to get a bit sluggish. My guess is around 150+ email notifications is where it would start getting that way.

    The other scenario I could foresee that happening is if you created thousands of deeply-nested categories without employing Flat Categories. The updates required from 1 post could bubble up to so many places it could slow things down.

    Both of these are rather narrow scenarios so they should be fairly easy to diagnose.

  • edited May 2018

    @Linc I think you maybe onto something suggestion the synchronous email.. could a slow SMTP server on my host be causing the delay? I just tried sending a test email within the dashboard and I'm seeing about a 6-7 second delay when sending to a single address. My emails send a banner logo, I can check to see if that's slowing things down too.

    Is there a reason emails are sent synchronously and therefore blocking the response? Seems asynch would be the way to go here so it's not blocking?

    @R_J thanks for other information I will give those things a try, it absolutely happens every time on mulitple browsers. I'm not doing anything unusual and only have maybe 20 users and a 1 category.

  • edited May 2018

    Looking more likely it has to do with sending email.. I guess perhaps it's my SMTP server??

    POST to https://packfansnation.com/dashboard/settings/emailtest takes 8 seconds before I receive a response for a single address for a NON-html formatted msg.

  • I switched from the default local SMTP server to a gmail SMTP server and delay issue is fixed! Well, down to 2-4 seconds. @Linc would love to know your thoughts on my question I posed above about sync/asynch for this... is there a way I could open a enhancement/feature request to have it switched to asynch if possible?

  • LincLinc Admin

    @PackFansNation said:
    Is there a reason emails are sent synchronously and therefore blocking the response?

    Yes: Native PHP is single-threaded.

    @PackFansNation said:
    Is there a way I could open a enhancement/feature request to have it switched to asynch if possible?

    Well, if you identify how that's even possible, I'd be happy to talk about it further.

    On cloud, we're moving towards a message queue system to do this. That requires further infrastructure support to implement much like Sphinx however, so I don't expect it to be something commonly available to open source.

  • @Linc I'm a nodejs guy which is async galore! I'm certainly not as familiar with PHP, but googling around revealed that it's possible to run threads in parallel... see -> http://docs.php.net/Thread and http://php.net/manual/en/book.pthreads.php

    Again I'm not as familiar with PHP, but that would indicate it's possible? Also possible is that maybe I'm missing something!

  • LincLinc Admin
    edited May 2018

    @PackFansNation said:
    Again I'm not as familiar with PHP, but that would indicate it's possible? Also possible is that maybe I'm missing something!

    The "pthreads" API isn't native to PHP, it's a PECL library. That means changing the minimum system requirements for Vanilla, which then goes down the rabbit hole of seeing what percentage of existing installs we think could meet that requirement (My guess: not many).

    The problem you're describing is perhaps more isolated than you realize. It's very unlikely to hit either scenario I laid out above, and I haven't heard many reports of slow SMTP responses. We use SendGrid for the cloud service and have no delay that we've been able to measure.

    At the end of the day, every platform has tradeoffs. In this case, I think trying to compensate for the tradeoff would be a net negative. A major PHP asset is that it's globally available; raising requirements undercuts that significantly.

  • @Linc fair enough, thanks for the quick response. Also thanks for pointing me in the right direction to be able to fix the issue.

Sign In or Register to comment.