| ||
|---|---|---|
| DO NOT EDIT OR POST REPLIES TO THIS PAGE. THIS PAGE IS AN ARCHIVE.
This page is an archive. Do not edit the contents of this page. Please direct any additional comments to the current talk page. |
Amazon EC2 feasibility?
Just came across this suggestion from one of our respondents to our survey:
- "See if you can work a way to run the wiki (but not the mysql database) on Amazon EC2 servers, or some other "elastic" server farm where, as an episode airs, you can for 1 day suddenly boost the resources with which you run it tenfold, while not paying a big bill. Amazon EC2 does this but does not have static storage for your database, which would mean a lot of bandwidth to a remote database. However, another hosting company might offer you virtual servers by the hour on a network where they also let you keep your dedicated server and sql database."
Is this feasible? Could we do this? Pros? Cons? -- Joe Beaudoin So say we all - Donate - Battlestar Pegasus 22:22, 26 February 2008 (CST)
- Well if there's a company out there that offers this for a reasonable price, why not? --Catrope(Talk to me or e-mail me) 03:53, 27 February 2008 (CST)
- This is almost like squaid server. The only time that we do have downtime or very werid slowness is near airing, which is true. But when we goto the Battlestar Forum during those times, its as fast as a button, with no slow down. My mind tells me that is just a Mediawiki I/O program when it comes to having to reteive the database. We might have to run that connection test script again (disable stats of course) again with mem-cache enabled. Directing everyone off to an off-site database is not the problem. We do that already with Athena, which is on a different subnet than Apollo, it be almost investing in a "Load Balanceing" hardware that we can place in front of Apollo that filters traffic more directly. WWW --> Load Balancer -- double split arrow --> Apollo + Athena. However, Athena never talks with the outside world, cept on the admin port and talks with Apollo internally at ThePlanet. Shane (T - C - E) 13:19, 4 March 2008 (CST)
- How about we set up a third DB server as a slave? It wouldn't have to be on a separate machine, it could run on Apollo. The other way around may even be better: have Athena do the hard work (servicing reads) and be somewhat lighter on Apollo (only writes). For more information on setting up master/slave DB servers in MediaWiki, go here. --Catrope(Talk to me or e-mail me) 07:49, 5 March 2008 (CST)
- I'm going to second Shane's comments regarding MediaWiki... During "Razor's" premiere and the two days following, the forum was fine, with the Wiki seeming to be the slowest. Coincidentally, when Apollo became bogged down, I had to deactivate the mysql database on Athena in order to get Apollo accessible via SSH, which tells me that Apollo was being the workhorse there... and was also being a bottleneck, apparently. So it seems to be that we need to beef up the Apollo server, and not Athena, which was fine even through the entire thing. -- Joe Beaudoin So say we all - Donate - Battlestar Pegasus 10:22, 5 March 2008 (CST)
- Have we yet figured out a way to simulate "battle" load, outside of trial by fire yet? It seems like most of the simulations so far have been less violent than the real deal. While it is not something we ought to subject our servers to on a whim, it would be nice to be able to test configuration changes before they face combat. --Steelviper 12:54, 6 March 2008 (CST)
- Someone familiar with the pywikipediabot framework (not me, I'd have to learn Python xD) could write up a bot that does lots of writes. Without it, we can really only simulate a flood of reads (I could write up something for that, though). --Catrope(Talk to me or e-mail me) 14:06, 6 March 2008 (CST)
- I think I understood that it was the concurrent edits (and edit conflicts that result) that were bringing us down. --Steelviper 14:47, 6 March 2008 (CST)
- Yeah, I wanted to say that (must've deleted it while rewriting): our largest problem is the edit flood, that's why we protect articles or put the wiki in read-only mode. We could maybe arrange for an edit fest, though: we all agree to submit a large number of edits more or less simultaneously (we can prepare them beforehand) at the Hangar Bay, and see what happens. IRC (Freenode?) would be useful to coordinate that. --Catrope(Talk to me or e-mail me) 14:58, 6 March 2008 (CST)
- I think I understood that it was the concurrent edits (and edit conflicts that result) that were bringing us down. --Steelviper 14:47, 6 March 2008 (CST)
- Someone familiar with the pywikipediabot framework (not me, I'd have to learn Python xD) could write up a bot that does lots of writes. Without it, we can really only simulate a flood of reads (I could write up something for that, though). --Catrope(Talk to me or e-mail me) 14:06, 6 March 2008 (CST)
- Have we yet figured out a way to simulate "battle" load, outside of trial by fire yet? It seems like most of the simulations so far have been less violent than the real deal. While it is not something we ought to subject our servers to on a whim, it would be nice to be able to test configuration changes before they face combat. --Steelviper 12:54, 6 March 2008 (CST)