vBulletin 5 - Painfully slow when saving any content, fast when updating

Collapse
X
 
  • Time
  • Show
Clear All
new posts
  • Cruisey
    Member
    • Apr 2018
    • 53
    • 4.2.x

    [Resolved] vBulletin 5 - Painfully slow when saving any content, fast when updating

    What are the system requirements for vbulletin with large amount of online users? We do not store files in database; we do not have a cdn.

    Our server:

    Code:
    Architecture:          x86_64
    
    CPU op-mode(s):        32-bit, 64-bit
    
    Byte Order:            Little Endian
    
    CPU(s):                4
    
    On-line CPU(s) list:   0-3
    
    Thread(s) per core:    1
    
    Core(s) per socket:    1
    
    Socket(s):             4
    
    NUMA node(s):          1
    
    Vendor ID:             GenuineIntel
    
    CPU family:            6
    
    Model:                 63
    
    Model name:            Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz
    
    Stepping:              0
    
    CPU MHz:               2095.148
    
    BogoMIPS:              4190.29
    
    Hypervisor vendor:     VMware
    
    Virtualisation type:   full
    
    L1d cache:             32K
    
    L1i cache:             32K
    
    L2 cache:              256K
    
    L3 cache:              20480K
    
    NUMA node0 CPU(s):     0-3
    Saving a content takes exactly 2mins just to get a respond for the javascript to update the dom.
    Last edited by Cruisey; Tue 18 Sep '18, 10:19am.
  • Wayne Luke
    vBulletin Technical Support Lead
    • Aug 2000
    • 73981

    #2
    The server information really doesn't help. We need to know the information in the sticky thread of this forum.

    https://www.vbulletin.com/forum/foru...swered-quickly

    Primarily -
    Web Server
    PHP Version
    MySQL Version

    For the Web Server, we recommend Apache 2.4.X over IIS. Some customers gain performance increases using NGINX but we do not provide direct support for this Web Server.

    For large sites, you should be storing attachments, avatars, and CSS in the file system. You should be using Memcached for your datastore and mid-length cache. You should have 256 MB allocated per PHP script.
    Translations provided by Google.

    Wayne Luke
    The Rabid Badger - a vBulletin Cloud demonstration site.
    vBulletin 5 API

    Comment

    • Cruisey
      Member
      • Apr 2018
      • 53
      • 4.2.x

      #3
      Originally posted by Wayne Luke
      The server information really doesn't help. We need to know the information in the sticky thread of this forum.

      Every support request should be in its own topic. Do not take over the support topics posted by others. The only thing that happens when you do this is make it more difficult to receive support. Often times we get threads like: This type of question is very difficult to answer because it provides no real information.


      Primarily -
      Web Server
      PHP Version
      MySQL Version

      For the Web Server, we recommend Apache 2.4.X over IIS. Some customers gain performance increases using NGINX but we do not provide direct support for this Web Server.
      Thanks.

      Web Server Apache 2.4.18
      PHP: 7.1.20-1+ubuntu16.04.1+deb.sury.org+1
      MYSQL: 5.7.23-0ubuntu0.16.04.1

      Hope that helps.

      Comment

      • Cruisey
        Member
        • Apr 2018
        • 53
        • 4.2.x

        #4
        Bumping......?

        Comment

        • Wayne Luke
          vBulletin Technical Support Lead
          • Aug 2000
          • 73981

          #5
          The versions are all acceptable. You might think about upgrading PHP to 7.2. You could also upgrade MySQL to 8.0. They don't tell me why you would be having this problem. What about the other questions in the linked topic?

          While I don't think the issue is query related, what does your slow query log look like?

          If you create a new topic instead of replying to a long topic with many subscriptions is it quicker?

          What are the exact steps to reproduce the issue?

          Does the problem exist in a new default style with no parent and without the extensive style changes that you have made?

          What about on a clone of the site without the heavy navigation bar?
          Translations provided by Google.

          Wayne Luke
          The Rabid Badger - a vBulletin Cloud demonstration site.
          vBulletin 5 API

          Comment

          • Cruisey
            Member
            • Apr 2018
            • 53
            • 4.2.x

            #6
            Hi

            Using the default theme, posting a topic or creating visitor message takes 2min. Though, I'll try to upgrade both php and mysql then report my findings.

            Something to note, when I press the post button, count to 3 then refresh the browser, the content is there. The issue is that, the response takes too long to return to "/content/text/ POST"

            Comment

            • Wayne Luke
              vBulletin Technical Support Lead
              • Aug 2000
              • 73981

              #7
              There is a lot going on when you create a new post. The system verifies the post to make sure that it meets all permissions, checks the BBCode to make sure it parses correctly, creates node, text, and closure table entries. In the case of the closure table, it will be up to 3+X where X is the depth of the channel records in the table. So if your channel is 5 layers deep there will be 6 new records for a topic starter, 7 new records for a reply, and 8 new records for comment. The system will also build the cache records for future access to this topic and index all of its keywords. Finally, it will loop through all subscriptions on both the channel and the topic to put together a notification list.

              This shouldn't take too minutes if everything is working right. What table engine are you using? We will install with the INNODB engine if it is available (and it should be on newer versions of MySQL). We do not recommend using MyISAM or ARIA table engines. In addition, each INNODB should be in its own file, not in a single compressed file as some MySQL servers are configured.

              Right now, I don't really have any information on your server configuration. This is really something where we need the database or direct access to the server.

              Try this...

              Best to do this on your staging server so you don't disrupt the production server.

              Edit the /core/includes/xml/logger.php file. Change this:
              Code:
                  <!-- <logger name='api'>
              <level value="trace" />
              <appender_ref ref="filelog" />
                   </logger> -->
              To:
              Code:
                  <logger name='api.content_text'>
              <level value="trace" />
              <appender_ref ref="filelog" />
                   </logger>
              Then open your /core/includes/config.php file and change:
              Code:
              // $config['Misc']['debuglogging'] = true;
              to:
              Code:
              $config['Misc']['debuglogging'] = true;
              Create some text posts. This should create a logfile on your server called vbdebuglog.log. What is the contents of that file?
              Translations provided by Google.

              Wayne Luke
              The Rabid Badger - a vBulletin Cloud demonstration site.
              vBulletin 5 API

              Comment

              • Cruisey
                Member
                • Apr 2018
                • 53
                • 4.2.x

                #8
                Im sure you meant /core/includes/xml/logger.xml.

                Did that but that vbdebuglog.log file is nowhere to be found on my server. Strange. Permission issue? This post had no help
                Last edited by Cruisey; Thu 20 Sep '18, 3:25pm.

                Comment

                • Cruisey
                  Member
                  • Apr 2018
                  • 53
                  • 4.2.x

                  #9
                  Update:

                  We've used Newrelic to spot the issue. The issue was when it was sending out the notification email. Long story short, we swiched to postfix to send the email and it's now blazing fast. Thanks for the support, Wayne!

                  Comment

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