Messages

Thanks for taking the time to post here. As of about 2:00 pm (EDT), the admins of ARMS wiki were made aware of this and took immediate action. In the future, you may receive a faster response by contacting one of the admins directly on the wiki.

Thank you again for reaching out!

The one on the hub works, but the one here (bar at the top) doesn't.

Oops, I didn't check the hub too. My mistake Naesala. 

An admin can probably fix that once one reads this thread.

The Metroid Wiki link is broken!

The link isn't broken. The site appears to be having some trouble right now.

Interesting stats! I should write a script that will compile a report like this each week and generate some graphs. It would be interesting to see how new game releases affect the wikis.

Zelda Universe (the site that hosts ZeldaWiki) seems to be down as well. Hopefully they'll be able to get all of this sorted out soon.

I believe they're currently transitioning to a new server. It should be back online any time now.

I've never seen a shared host offer a PHP accelerator, so I'm sure there's some technical reason as to why they can't offer them.

I seem to get only intermittent delays though.  Sometimes the pages load fast, sometimes really slow.  Hmmm.

That's pretty typical for a shared host. Because you're sharing the same server with other customers (see below), your load times depend not only on your own traffic, but on the traffic of everyone else as well. So if another site on the same server is experiencing a huge increase in traffic, your site performance will suffer as well. We used to have this issue with Nookipedia, which is why I eventually moved us over to a VPS at Linode. Needless to say, our site's speed is much faster now.

I ran a reverse IP lookup for your wiki, and found that the following sites are also hosted on the same server:
[spoiler="List of Sites on your Server"][/spoiler]

[$wgMainCacheType = CACHE_NONE;]

If you have xCache installed, you may be able to use it for Object caching. See this page for more information.

Essentially, you just change $wgMainCacheType = CACHE_NONE; to $wgMainCacheType = CACHE_ACCEL; in LocalSettings.php. If you notice a speed increase, that means it's working. You may want to ask your tech guy about it first though.

So, for those of you on BlueHost and Linode, did you manually install some sort of caching accelerator?  I'm experimenting with the file caching mechanism, but I'm skeptical that it will help. 

What are your wiki's config settings to improve performance?

Nookipedia uses APC for opcode caching as well as the file cache, and it works really well. APC is really easy to install, and it works almost automatically. You may need to go in and tune some of the settings for your server, but otherwise it works like a charm and really speeds things up.

You may also want to check out the MediaWiki guide to improving performance, if you haven't already: http://www.mediawiki.org/wiki/Manual:Performance_tuning

starting at $20 a month, till i get a hire paying job.

Linode is a great VPS to go with in that case. Just install either the LAMP or LEMP stackscript and you'll be good to go!

Great post Tappy.  While I love the possibility of not sharing a server, I'm not sure it will ever be financially viable for many of the NIWA wikis or the Dragon Quest Wiki.  I don't even put ads on our wiki because I simply don't think there will ever be enough revenue to be worthwhile.  As a result of the shared server, there are definitely times when a page load seems to stall for no reason.  I attribute this to the shared server getting slammed by some other site. 

Our wiki was moved from Wikia, so now that I have access to viewing the monthly visit stats, I can make some better judgements going forward based on our visit numbers.  Moving from Wikia was a pain in the @#$, because I had no access to the server at all.  They release free database dumps on request, but were using an older version of MediaWiki than the one hostgator would auto-install.  So I ended up installing the older version of MediaWiki myself (pain), then importing the database (more pain), then upgrading MediaWiki (even more pain). 

Then for the media, I had to write a script to scrape all the images and import them into the new wiki.  I'm sure than any future host changes will HAVE to be easier than this one was.  But we are months beyond that now and everything has been pretty good. 

Shell access is pretty important because I know of no other way to run maintenance scripts.  I don't think there is a way to do that unless you can install something to the server (probably can't).

I believe there is a MediaWiki extension that allows you to run some of the maintenance scripts.

Nookipedia also uses Linode as a host, and we have not had any problems with them so far. I can also back up Tappy's claim that tickets are always answered in less than ten minutes.

Yes that's exactly right.  Your post led me to realize that Bulbapedia is storing media in a location outside of /w/, which is why their rules are similar, but images still get crawled.  I guess the solution is to move the media somewhere else.

It looks like almost all the other NIWA wikis are doing the same.  All except Lylat and Nookipedia.  Nookipedia lets crawlers go everywhere, I would assume Lylat does as well.

I didn't realize our robots.txt file was set up like that. There were supposed to be some rules in there about special pages and skins. Thanks for letting me know.

I agree. I think the choice to move the game over to the GBA was a good one.

Updating SMF would probably fix the problem, unless there's something preventing us from doing that.

Like many others, Joshua was the first person I met here at NIWA. He helped me to become involved in the community and always gave encouragement and feedback to new wiki startups. Needless to say, Nookipedia would not exist without him. I'm really saddened by this news, and I know that it won't feel the same around here without him.

Rest In Peace, Joshua.

If you have permission, you can also use Special:LockDB to shut down editing until your server admin can add that code.

I think we really need to reopen discussion of using a different (self hosted) search engine. 100 searches per day could become a problem during some months with heavy traffic. Also, as others have pointed out, Google isn't prioritizing the smaller wikis that have better information for some searches. This leads to our uses not getting the best information possible. Being able to control how searches are handled is really important if we want to deliver the best possible hub site experience.

There are some great open source search engines that would allow us to do this relatively quickly, and for free.

(Edited to reflect mistake. Thanks Greenpickle!)

We're currently discussing the possibility of making that topic public. Stay tuned.

Well not exactly. Chromium is the browser itself. However, in an effort to make it more user friendly, Google rebrands it as Chrome and adds features that users need like auto-updates and Flash. That's really the main difference. As Greenpickle said, most linux distributions use Chromium because a Google branded Chrome isn't directly available.

I'm going to side with Tina on this one, going with the Lucas & Kumatora combination. Wess is also pretty funny.