Announcement

Collapse
No announcement yet.

Slow Posting response when posting to SOME threads

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • bacemail
    replied
    Great thread. I am experiencing the same problem with 3.8.4.

    Leave a comment:


  • siliconfinance
    replied
    Hi Steve, I am just about to submit a support ticket, but it sounded like we were experiencing similar issues so I had hoped someone who found a solution might be willing to share it.

    Leave a comment:


  • Steve Machol
    replied
    Please start your own thread with all the relevant details. Thank you.

    Leave a comment:


  • siliconfinance
    replied
    Bump

    Leave a comment:


  • siliconfinance
    replied
    Same problem here. Anyone find a cause or a solution, yet?

    I am running vB 3.8.3
    PHP 5.2.6
    MYSQL 5.0.67-community
    Apache v2.0.63

    Leave a comment:


  • bstillman
    replied
    Same here. It's very intermittent though.

    Leave a comment:


  • lingstar
    replied
    Chalk me up to another person who has the same issue. The time between posting and actually seeing the post go thru is abnormally long.

    Does anyone have any other suggestions?

    Thanks,

    Barbara

    Leave a comment:


  • looknow12
    replied
    We are running 3.6.8 and also have the same exact problem. It takes 30-40 seconds to get a response back when posting a reply or submitting a new post.

    There is no third party code installed and no mods. Please help.

    If this has been fixed in another version, find we will upgrade, but need to know this first before blindly upgrading.

    Incidentally, if I open a new browser I see the post is made immediately (well fast anyway).
    Last edited by looknow12; Wed 11th Feb '09, 8:15am. Reason: added comments

    Leave a comment:


  • VladZaitsev
    replied
    Originally posted by flynnibus View Post

    Reason is the html convo is different between a quick post reply and the full editor. The quick post reply does an ajax thing where the page is not actually redrawn fully. If you use the full editor, when you hit post, you get a 302 to showthread.php or if you have redirect pages enabled, you should get the please wait, which then leads to the showthread page.
    .
    Look at http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html

    10.3.3 302 Found
    ...
    If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
    ..,


    So when we POST message etc. we MUST set "Remove Redirection Message Pages= Off" and show user message abiout redirecting as RFC required if Vbulletin use 302 code .


    10.3.4 303 See Other

    The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource


    May be Vbulletin fix redirect probrem like RFC require?

    In my case "Remove Redirection Message Pages= Off" fix problem with slow POST redirects to showthread.php

    Leave a comment:


  • Removed-1078464
    replied
    Anyone have any updates on this issue? Jelsoft Staff have you come across anything new pertaining to this issue? My site has been up for about 3 years now and use to work very quickly the first two years when creating new threads and replies, but the last year or so I too have noticed that when I create a new thread it can take on average of up to 20 to 30 seconds for it to actually refresh the screen and show the new thread content. Nothing has changed in the past year regarding modifications, only the number of members (45) and posts...

    Doug

    Leave a comment:


  • tagthis
    replied
    We've got the same thing.

    Basically after looking at the server, mysql, php, the network, the path the network uses, MTU, and a bunch of other stuff we've finally settled on it being something to do with browser type.

    Can anyone who's getting the issue try and get someone to use Firefox 2.0.0.13 to see if they still get the issue?

    Worth noting not all IE7 installations are effected but all IE6 users on our site seem to have the issue.

    We've had users go from 10-15 second load times down to 2 seconds with FF2.

    If someone could try the browser theory out I'd really appreciate it.

    Leave a comment:


  • Jay Luto
    replied
    I'm replying to this message in hopes of tracking the progress. I'm experiencing the same problem with Quick Reply and Edit.

    Keep us all in the loop !Thanks.

    Leave a comment:


  • flynnibus
    replied
    We may have uncovered something.. at least with quick testing last night we had better success. It doesn't match my results 100%, but we saw a marketable improvement in our production site in quick testing. Those of you who have been experiencing this problem, please PM me as I'd like to ask a comparison question.

    Jelsoft has not been helpful at all with the support ticket. They basically suggested the same things outlined at the begining of this thread (which we did before even opening the thread) and then said ask in community support. Great paid support

    Leave a comment:


  • flynnibus
    replied
    Originally posted by buddy View Post
    Good luck. I been having this problem for a year now. Lost 95 % of the users.
    well I got a good dataset now on a slow one.. but not max slow. This one was about a 25 second delay.. on a vb install with all plugins disabled and the styles at default. maybe now they'll actually consider looking at it. It's not the max 1.5 minutes that I've seen, but the behavior is consistent. I'm opening a ticket.. cross your fingers.

    Leave a comment:


  • buddy
    replied
    Good luck. I been having this problem for a year now. Lost 95 % of the users.

    Leave a comment:

widgetinstance 262 (Related Topics) skipped due to lack of content & hide_module_if_empty option.
Working...
X