Announcement

Collapse
No announcement yet.

Slow Posting response when posting to SOME threads

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

  • flynnibus
    replied
    Well.. I'm still been experimenting.

    What I've found I believe is the problem is always in the showthread.php response after posting.

    If you have redirects on, when the user submits a post, then get a HTTP 302 redirect to /showthread.php almost instantly. But the server is very slow to respond to the showthread.php request.

    The debug information is also not reflecting the total story as well.. which makes me wonder if its webserver related in some way.

    For instance, I had a slowdown now, but a very minor one. In this case, when I hit submit, within 0.5 seconds, the server has responded with the 302 redirect. The redirect causes the client to close the existing tcp session and open a new one.. this only takes 0.06 seconds and my client submits the HTTP GET for the new showthread.php page. The server immediately ACKs the packet, but It then takes 6 seconds before I get the first data back from the server.. after which once the data starts flowing it takes only 0.3 seconds to transmit the page and close the tcp connection.

    So in this simple case, there is a 6 second delay from when the http get is recieved and when it starts spitting out data.

    But if you look at the vb debug for that exact posting... according to vb it only took
    • Page Generation 0.50193 seconds
    • Memory Usage 4,239KB
    • Queries Executed 14


    To build that page. So if php thinks its only taking .5 seconds to generate the page, why is it taking 12x longer before the data actually starts flowing to the client?

    I haven't nailed it down completely.. but that seems to be consistent in what I've seen so far. vb debug showing less then a second, yet it taking upwards of 1.5 minutes to actually get the page from the server. Yet, this slowdown ONLY seems to happen in posting.

    Leave a comment:


  • terryp3
    replied
    Me too. I came in looking for answers for the exact same problems. I've been running VB forums for nearly 4 years, upgrading when necessary and have never had these issues before. It's making a lot of my users very frustrated which is understandable.
    If needed I can issue a support ticket because I really need a solution.

    Leave a comment:


  • Webber
    replied
    Anyone get close to a possible solution to this issue?

    I am still experiencing the same issues so I thought I would check here for updates. Thanks in advance.

    Leave a comment:


  • Rick Horwitz
    replied
    Originally posted by Webber View Post
    Just thought I would let you know that I have two VB 3.6.8pl2 running on two seperate servers --- one on my own server and another with an ISP.

    The one on the outside ISP was stock no plugin's etc. and it is hanging on the new posts via quick reply, advanced and when editing.

    I am not a coder but it seems that something with the posting code is hanging up.

    Also, I didn't experience this prior to 3.6.8.

    I hope this helps to get this solved.
    I came here looking for an answer to the same question. Obviously it is something with the code, if your OOTB version is hanging.

    Time for Vb to take a serious look yet??

    Leave a comment:


  • Webber
    replied
    Originally posted by flynnibus View Post
    For those that have seen this... can you isolate the following?

    - do you have Remove Redirection Message Pages enabled under Cookies and HTTP Header Options in vb options?

    - do you notice its only when you do not use quick reply? IE - its only when you use the editor on its own page?

    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.

    The debug counters point as if this problem is in the showthread or html transmission - but I've also noticed you can't trust the debug timer count religiously either. On some pages I've seen it have numbers like 112323 for a page that drew nearly instantly.
    On both sites my redirection is turned on.

    I see the problem nearly 100% of the time using the quick reply form and edit post. But in this area:
    Enable Clickable Message Formatting Controls I have Enabled Standard & WYSIWYG controls on all three: Full Editor; Quick Reply; and QUick Edit.

    I see this in both IE and have had reports of the same thing with FireFox and I think Opera browsers.

    I don't know how to to test the with the debug/queries or if I have uncashed templates so I can't provide any more details as it relates directly to these.
    Last edited by Webber; Tue 5 Feb '08, 2:44pm.

    Leave a comment:


  • flynnibus
    replied
    For those that have seen this... can you isolate the following?

    - do you have Remove Redirection Message Pages enabled under Cookies and HTTP Header Options in vb options?

    - do you notice its only when you do not use quick reply? IE - its only when you use the editor on its own page?

    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.

    The debug counters point as if this problem is in the showthread or html transmission - but I've also noticed you can't trust the debug timer count religiously either. On some pages I've seen it have numbers like 112323 for a page that drew nearly instantly.

    Leave a comment:


  • flynnibus
    replied
    Originally posted by Webber View Post
    Just thought I would let you know that I have two VB 3.6.8pl2 running on two seperate servers --- one on my own server and another with an ISP.

    The one on the outside ISP was stock no plugin's etc. and it is hanging on the new posts via quick reply, advanced and when editing.
    Webber - please open a ticket so maybe Jelsoft will actually start looking at these issues.

    I can't disable my site for the long periods it would take to replicate this fully for them to look at it themselves - and to date they don't seem interested unless you can do that.

    If I can catch it well with a sniffer again, I can look further into it. My guess is its something with the follow-up page being displayed. Possibly prior to 3.6.8 maybe the posting method was different. That can be tested by checking out an earlier version as well.. which might be worth looking at.

    I suppose if we had the redirect pages in place.. we probably wouldn't see this. But it sure would be nice if we didn't have to brute force our way through this!

    Leave a comment:


  • Webber
    replied
    Just thought I would let you know that I have two VB 3.6.8pl2 running on two seperate servers --- one on my own server and another with an ISP.

    The one on the outside ISP was stock no plugin's etc. and it is hanging on the new posts via quick reply, advanced and when editing.

    I am not a coder but it seems that something with the posting code is hanging up.

    Also, I didn't experience this prior to 3.6.8.

    I hope this helps to get this solved.

    Leave a comment:


  • flynnibus
    replied
    I caught it again today under debug... the debug values are all low in this situation. It was taking a VERY long time this time, so I quickly fired up the packet sniffer to try to capture what was happening.

    All I did was see that there is a long period where there was NO traffic, and then an existing data transfer continued and ended with the http 200 from the server.

    With the sniffer ready, I tried to reproduce the situation, but was not able to capture the situation, but did see that the behavior is

    when user posts, it does a HTTP POST to newreply.php for which the server responds with a 302 redirect to actually showthread.php

    So the software must accept the post, and then redirect you to showthread.php to display the new version of the thread. So instead of acknowleding the post with a HTTP 200, which would free the browser up, the 302 redirect causes the browser to try to reload showthread.php before the webpage frees up from the 'post quick reply' button.

    However, without getting it for real, it would appear right now that the long pause is actually in the showthread.php response... because in my one capture, there was nothing for 70 seconds, and then boom I got some data and the http 200 and then the page displayed quickly.

    But again, the debug results were pretty useless to ID the true delay, because debug values shown for showthread.php were tiny. But that debug should be for the showthread.php query.. so according to vb, that page is processing through the php instantly but for some reason the webserver is completely dogging replying to the http get on showthread.php=xxxxx

    This last data would point to a problem with the webserver with that one session (even though other sessions are cranking normally). But I really need to capture a full sniff at the time of delay to get details on that. Which of course is brilliantly hard considering the inconsistency of the issue.

    Leave a comment:


  • Cbrown
    replied
    Ok.. well, I ended up doing a repair/optimize ALL the tables... That seems to have made it better and now I'm not seeing any delays.

    CB

    Leave a comment:


  • flynnibus
    replied
    So far I have seen it once while I have debug enabled.

    The timers all on the page all are under .5 seconds total. The query count was similar to a page that does not slow down.

    So at least according to vbulletin's debug, the slowdown is not happening server side.

    However, again, since Jelsoft will not give us guidance on what the posting action actually does, we are left to diagnose what the next step could be.

    A brief sniff shows that the post and response isn't actually the full webpage itself, but may be some client-side rendering. We are wondering if maybe some open tags or something is what is causing the slow-down. But it doesn't happen all the time, so I don't think it would be something in the templates, etc. That might also explain why some threads show it more then others (if the tag problems are in the posts themselves).

    Our next step is going to be looking at what the actual webpage looks like, and check out the page source afterwards to find anything that might be freaking out the browser.

    Again, debug shows NORMAL php and database stuff and the timers are all less then .5 seconds total and yet the browser still takes 20-30 seconds to finish rendering the page after hitting submit.

    Leave a comment:


  • Cbrown
    replied
    Yup.. I'm having this same issue too and hence found this thread. I ended up adding more RAM and rebooting my server's services.

    That seemed to help a little bit, but I don't know if it's just a coincidence. Today I'm having issues with the PM's being horribly slow.

    Yes.. the data goes through immediately. But the page does not refresh. Just hangs up.

    If I open another tab and look... The site pops up fast and there is my sent message, post, whatever.

    The OTHER tab is still waiting, and takes about 30 seconds and finally refreshes, to show what the other tab has already showed.

    Any word on what MIGHT be causing this? I do not run modifications.... This is 3.6.8

    Leave a comment:


  • Webber
    replied
    Has this issue been resolved? I have the same exact issue and am looking for a solution. Thanks in advance.

    Leave a comment:


  • flynnibus
    replied
    Originally posted by Steve Machol View Post
    When an issue cannot be duplicated with the default vB code, then this is standard procedure to troubleshoot the problem. It has nothing to do with CYA as you so nicely put it.
    Then why not tell someone how to debug it rather then say 'reboot'

    As for it not being duplicated with the default vb code - how do you know? You haven't isolated the conditions that cause it to fail - can you claim it doesn't exist?

    Rather then look at any problem, your answer is always 'default it'. I understand the burden of dealing with 3rd party code - but there is a difference between SUPPORTING third party code and denying support for your product when it exists. Usually you work to isolate the two - but your standard answer is 'default it'. When your server misbehaves - Microsoft doesn't demand you remove all installed programs before they even take your call.... which seems to be the Jelsoft Support SOP.

    Your support policy of 'default or we don't even talk' is what is tiresome. You expect me to default the entire site BEFORE telling me how to even diagnose the situation. So when I sit around at 3am, disable everything, and the problem still happens - then what?

    Instead we are forced to work around the blackbox of vbull because changing the entire production site isn't practical and duplicating the site doesn't give a real equal either, but that is all we are left with.

    We are currently using the debug mode in a parallel site to try to dig into the php operation when the slow down is observed.

    See... a GOOD support organization would start by helping ID what the posting operation goes through so you can start to monitor which part of the process is the one getting stalled. Instead your lack of support forces someone to treat the entire process one one big black box.. from the time the user hits submit.. to when the page is redisplayed to the poster, rather then looking at the elements of the post being submitted, to the web server.. to the vbull code processing the post, the database writes, any post-processing that happens after a post is submitted, to having the thread page redrawn for the user. We've isolated that its not the db speed, we know its not network between the user and server, we know other pages are being served full speed during the 'stall', and we know the post has been committed to the post table at least at full speed because we know other viewers see it immediately.

    A GOOD support organization would work to ID/describe what happens during that period for the user so that the proper tools can be used to diagnose those steps. Once the problem area is ID'd, then you go and identify if its an 1st or 3rd party induced problem.

    Instead we get the POOR service which puts the support organization's needs ahead of the practicality of the world the customers live in.

    In our TAC we have to deal with all kinds of 3rd party problems we can't control, but you work to ID the root cause - rather then demand the customer put own product in a total vacuum before helping them understand where and how the dependencies work together. Not believe that the world is a perfectly clean white sheet of paper and demand everyone else think the same way.

    Leave a comment:


  • Steve Machol
    replied
    Originally posted by flynnibus View Post
    The CYA approach of Jelsoft is getting tiresome rather then actually LOOKING at the issue at hand before suggesting people take their site down to revert everything. So what if it still happens, then what? I still don't have any methods to diagnose or work with it. So I stay up late at night, take my site down, and still don't get anything done.
    When an issue cannot be duplicated with the default vB code, then this is standard procedure to troubleshoot the problem. It has nothing to do with CYA as you so nicely put it.

    If you do not like this and want to keep you modifications, then you can try asking for help at www.vbulletin.org

    Leave a comment:

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