User talk:Steelviper: Difference between revisions

Discussion page of User:Steelviper
(→‎Server stuff: still looking for silver bullets...)
m (Archiving 1 thread(s) (older than 24h) to User talk:Steelviper/Archive3.)
Line 6: Line 6:
}}
}}
{{ArchiveTOC}}
{{ArchiveTOC}}
== Server stuff ==
* Hi, Matt.  I got the message you left [http://heroeswiki.com/User_talk:Admin#Comparing_Notes here] and I'd be more than happy to lend some suggestions.  I'll leave the entire discussion here, you can point any interested parties to your talk page.  I have some questions for you guys for starters.  If you don't want some of this info public for some reason, then my email address is on my [http://heroeswiki.com/User:Admin Heroes Wiki user page]:
# You said you have two servers.  Could you explain what pertinent services are running on each (i.e. are both webservers, or is one a db server and one a web server)?  What are the memory and processor specs of each one?
# How many hits are you seeing during your peak day (this can include images, pages, etc.)?
# During your periods of high load, what metrics are you seeing?  High load average, high cpu utilization, high IO utilization, or simply sluggish response time?  If it's high cpu utilization can you pinpoint a single process or group of processes that are taking all the CPU time?  Is this occurring on one server of both?
# Do you have any PHP caching extensions installed?
# Are you using any web-accelerators (Squid, etc.)?
--[[User:HeroesWiki|HeroesWiki]] 17:50, 5 December 2007 (CST)
: Hi Brian! Our server specs are [[BW:SERVER|located here]]. "Apollo" is our apache server, while "Athena" is our database server. Also, I posted a [http://blog.battlestarwiki.org/2007/11/26/preliminary-web-numbers/ blog entry on our numbers for 11/24], and I'll get you the following days numbers as soon as Webmin can generate them from the logfiles. As for the server lag, it happens on the "Apollo" server exclusively, and I highly supsect the culprit is apache.
: At one time, we did have Squid installed, but it caused problems with the blog and, since we had upgraded to newer servers at the time, we haven't used it since. -- [[User:Joe Beaudoin Jr.|Joe Beaudoin]] <sup>[[User talk:Joe Beaudoin Jr.|So say we all]] - [[Battlestar Wiki:Site support|Donate]] - [http://www.sanctuarywiki.org Sanctuary Wiki &mdash; ''New'']</sup> 23:10, 5 December 2007 (CST)
::We're not using Squid :O ? We should be. It also seems we don't have [http://meta.wikimedia.org/wiki/Memcached memcached], which we really should be running. --[[User:Catrope|Catrope]]<sup>([[User talk:Catrope|Talk to me]] or [[Special:Emailuser/Catrope|e-mail me]])</sup> 08:34, 6 December 2007 (CST)
::: It doesn't sound like you need Squid too much at this point.  If your read activitiy started causing problems then Squid would be a good idea.  It looks like you're running into a similar problem that I did back in May with my old server (which is comparable to the web server you're using).  I strongly recommend looking into [http://www.php.net/apc APC].  PHP is an interpreted language and when you have a lot of people hitting the site and editing articles then PHP can consume a lot of resources.  APC will allow PHP to cache the MediaWiki PHP opcode.  Before APC the server was very sluggish under load.  During the season one finale the load average was between 13-26 constantly.  By simply dropping APC in the average dropped down to about 1-2 and the site responded so well.  Once you see how the site performs with APC then it'll be easier to determine if any changes in hardware are required.  For reference Heroes Wiki is using dual quad-core 1.6ghz processors and never even breaks a sweat (though I purposely over-speced it to allow for significant growth).  --[[User:HeroesWiki|HeroesWiki]] 08:34, 7 December 2007 (CST)
:::: Interesting. I wonder how that will work with the dynamic PHP of the forums and the blog. :o [[User:Shane|Shane]] <sup>([[User_Talk:Shane|T]] - [[Special:Contributions/Shane|C]] - [[Special:Editcount/Shane|E]])</sup> 13:27, 7 December 2007 (CST)
:::::Let's find out! Maybe try to work it into a Tuesday/maintenance day? It sounds like it may be just the ticket... --[[User:Steelviper|Steelviper]] 14:56, 7 December 2007 (CST)
::::: PHP itself is typically rather static while content it's used to display is very dynamic. Where Squid may cause issues with stale dynamic content, APC is only caching the php opcode itself and not the content that it's returning so it won't affect it. APC is also a generic PHP opcode cache so it's not tied to MediaWiki for instance. It will accelerate any heavily used PHP application. In fact if the application has hooks for APC built in it can further take advantage of it by using shared memory for holding global variables (MediaWiki does include specific hooks for APC to take advantage of this as well, but your biggest improvement will be the opcode caching alone).  FYI I use apc.shm_size=512 to allocate 512MB of RAM for the opcode cache.  If you try out APC you may need to tweak this value to reach the right balance of performance vs memory utilization for your particular sites.  --[[User:HeroesWiki|HeroesWiki]] 15:01, 7 December 2007 (CST)
Did you get a chance to try out APC yet?  If so, has it been helping?  --[[User:HeroesWiki|HeroesWiki]] 13:35, 19 December 2007 (CST)
:Not yet. I been busy with work. I will have to find a "day" that I can work on it. [[User:Shane|Shane]] <sup>([[User_Talk:Shane|T]] - [[Special:Contributions/Shane|C]] - [[Special:Editcount/Shane|E]])</sup> 13:39, 19 December 2007 (CST)
::Still a nogo? I was hoping we'd be able to get this up and tested prior to the march premiere. --[[User:Steelviper|Steelviper]] 13:16, 15 January 2008 (CST)
:::We looked into it and couldn't see a preformence "increase" with our setup of one instance of the mediawiki files for all the wikis. [[User:Shane|Shane]] <sup>([[User_Talk:Shane|T]] - [[Special:Contributions/Shane|C]] - [[Special:Editcount/Shane|E]])</sup> 13:20, 15 January 2008 (CST)
:::1.12 should also improve performance, as 1.11 auto-purges all pages containing magic words (like <nowiki>{{CURRENTTIME}}</nowiki> or <nowiki>{{PAGENAME}}</nowiki>) every hour. 1.12 only autopurges pages containing magic words whose output actually changes, so pages containing <nowiki>{{PAGENAME}}</nowiki> or <nowiki>{{SUBPAGENAME}}</nowiki> (we have quite a few of both in the Battlestar Wiki namespace) don't get autopurged anymore. I don't know when 1.12 will be released, but I hope it'll happen before April 4 (I'll ask). --[[User:Catrope|Catrope]]<sup>([[User talk:Catrope|Talk to me]] or [[Special:Emailuser/Catrope|e-mail me]])</sup> 13:22, 15 January 2008 (CST)
::::We (/you... I don't REALLY do much of anything) didn't even try it? Would it it pay off if we had a separate instance for the EN site vs the rest of the sites? I don't want to beat a dead horse, but I still wouldn't consider us "there" yet on performance. I'm glad we actually stayed up through the "Razor" premiere, but we still had to lock down pages and performance was rather draggy. Ideally we'd be able to eliminate both of those issues, though it may just be a matter of not enough horsepower (and we really can't justify much more price wise for the servers). --[[User:Steelviper|Steelviper]] 13:48, 15 January 2008 (CST)

Revision as of 06:03, 17 January 2008