• Register
    • Help

    striker  0 Items
    Currently Supporting
    • Home
    • News
    • Forum
    • Wiki
    • Support
      • Manage Subscriptions
      • FAQ
      • Support For
        • VaultWiki 4.x Series
        • VaultWiki.org Site
    • What's New?
    • Buy Now
    • Manual
    • 
    • Support
    • VaultWiki 3.x Series
    • Bug
    • Installed 3.03 from 3.02 and CPU is going crazy again

    1. Welcome to VaultWiki.org, home of the wiki add-on for vBulletin and XenForo!

      VaultWiki allows your existing forum users to collaborate on creating and managing a site's content pages. VaultWiki is a fully-featured and fully-supported wiki solution for vBulletin and XenForo.

      The VaultWiki Team encourages you to join our community of forum administrators and check out VaultWiki for yourself.

    Issue: Installed 3.03 from 3.02 and CPU is going crazy again

    • Issue Tools
      • View Changes
    1. issueid=1951 August 27, 2010 3:38 PM
      Trekkan Trekkan is offline
      Junior Member
      Installed 3.03 from 3.02 and CPU is going crazy again

      In 3.02 I had disabled the two plugin's mentioned and the CPU usage went back to normal.

      I saw 3.03 was released and installed that. Checked and those two plugins don't exist anymore, thought all was good. But ever since I did that, my CPU is going nuts again. I disabled VW and it's back to normal in seconds. I'm on a hosted machine, so I don't have access to anything outside of CPanel stuff. I'm hoping someone else has a problem as well that can provide more information.
    Issue Details
    Issue Number 1951
    Issue Type Bug
    Project VaultWiki 3.x Series
    Category Performance
    Status Not a Bug
    Priority 5 - Minor Bugs / Small Tweaks
    Affected Version 3.0.3
    Fixed Version (none)
    Milestone VaultWiki 3.0.5
    Software DependencyAny
    Users able to reproduce bug 0
    Users unable to reproduce bug 0
    Attachments 0
    Assigned Users (none)
    Tags (none)




    1. August 27, 2010 7:32 PM
      pegasus pegasus is offline
      VaultWiki Team
      Is there a particular feature that your wiki uses very frequently, that other wikis might not use so much?

      Do you have any widgets that display online-locations information on forum-home or another index page?
      Reply Reply  
    2. August 28, 2010 2:45 PM
      pegasus pegasus is offline
      VaultWiki Team
      I have a feeling this is the AJAX link pop-ups. I notice that when I hover over about 10 links on a page that trigger pop-ups, this causes a small spike in CPU. It's likely that if many users are doing this at once, this can cause a more significant CPU spike.

      In AdminCP > Settings > Options > VaultWiki: General Settings, set "Enable AJAX Previews of Wiki Articles" to "No". If you notice a significant drop in CPU, the method for generating the pop-ups will have to be revisited: http://www.vaultwiki.org/issues/1955/

      I have also seen spikes in CPU for wikis that over-use wiki templates (like several hundred in one article). I would consider the average template usage to be < 10 per article, so if you fall above 10 per article, you may notice an increase in CPU. We have tried to improve the performance of certain templates here: http://www.vaultwiki.org/issues/1952/
      Reply Reply  
    3. August 29, 2010 4:56 PM
      Trekkan Trekkan is offline
      Junior Member
      Currently my Wiki is in it's very infancy, so there's not a lot of usage/articles there yet, so suggestion #2 wouldn't apply. I'll check into #1 though. Although lately things have seemed better.

      Is there anything that would cause CPU spikes after turning the Wiki on, that would then settle down? Caching types of things or something?
      Reply Reply  
    4. August 29, 2010 5:23 PM
      pegasus pegasus is offline
      VaultWiki Team
      Yes, caching of certain items would begin immediately after turning the wiki on, but other types of caching would require visitors.

      You might get an influx of visitors that suddenly realize the wiki is back on so they can read that article they wanted to read last week - that also requires a little time to settle down, once everyone feels like they are up-to-date again.

      Scheduled tasks would not have occurred since you disabled the wiki. Enabling the wiki would cause the scheduled tasks to play catch-up.

      I have found that rebuilding forum styles, plugins, settings, or any cached items like that cause a spike in CPU. This typically happens (sometimes multiple times) when enabling / upgrading the wiki. It would also happen during what may seem like small tweaks to your templates or settings. If you are storing stylesheets (or any other cache) in the file system, updating a large number of files like this at once causes a CPU spike too. If you are using mods like vBOptimise or vBSupercharged, then you have more caches that all need to be updated.
      Reply Reply  
    5. August 29, 2010 6:47 PM
      Trekkan Trekkan is offline
      Junior Member
      Ok, after your last message I think I can attribute the most recent issues to the caching and updating, scheduled tasks, etc. Right now things seem to be running pretty good and you can probably close this thread as a non-bug at this point.

      Thank you for all of your time on the issue!
      Reply Reply  
    + Reply

    Assigned Users
    Loading Please Wait
    Tags
    Loading Please Wait
    • Contact Us
    • License Agreement
    • Privacy
    • Terms
    • Top
    All times are GMT -4. The time now is 11:05 AM.
    This site uses cookies to help personalize content, to tailor your experience, and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Learn more… Accept Remind me later
  • striker
    Powered by vBulletin® Version 4.2.5 Beta 2
    Copyright © 2023 vBulletin Solutions Inc. All rights reserved.
    Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2023 DragonByte Technologies Ltd.
    Copyright © 2008 - 2013 VaultWiki Team, Cracked Egg Studios, LLC.