Announcement

Collapse
No announcement yet.

Slow Posting response when posting to SOME threads

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

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

    Comment


    • #17
      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

      Comment


      • #18
        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.

        Comment


        • #19
          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

          Comment


          • #20
            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.

            Comment


            • #21
              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.

              Comment


              • #22
                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!

                Comment


                • #23
                  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.

                  Comment


                  • #24
                    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 5th Feb '08, 3:44pm.

                    Comment


                    • #25
                      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??

                      Comment


                      • #26
                        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.

                        Comment


                        • #27
                          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.

                          Comment


                          • #28
                            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.

                            Comment


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

                              Comment


                              • #30
                                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.

                                Comment

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