Forum - View topicCan we get a reason why ANN was down?
|
Goto page Previous 1, 2 |
| Author | Message | ||
|---|---|---|---|
Teriyaki Terrier
 Posts: 5689 |
|
||
As a person who usually likes to hear/read behind the scenes information either for fun or information purposes, I am very inclined to agree with you on this one. It's not that that I don't understand the curiosity and wanting to learn potentially interesting (sometimes comedy gold material, in it's own right) but in a case like this I am just glad ANN is back in running and it's back to way the site normally is doing. Brand news articles, reviews etc. Like Rukiia, Zac also brings up a valid point as well, given that the problem is fixed and has been fixed for a while now, there really is no point in dwelling on this issue. I am pretty sure this issue will be talked about (candidly perhaps?) and if there is information that needs to be addressed, it will likely be done so in the weekly ANN pod cast. But again, I see why there is interest in knowing about the specific details on this matter, but I personally am just glad ANN is doing fine now. |
|||
|
|||
|
vashna
Posts: 1313 |
|
||
|
I am honestly just glad that the troubles are behind us. When I first saw that the website was experiencing some problems I was greatly concerned, because I had never seen ANN suffer any sort of technical difficulty at all. The uptime, in my opinion, had been amazing. I am actually kind of sorry that Chris had to make such a sacrifice.
|
|||
|
|||
The American Average
 Posts: 645 Location: Jehuty |
|
||
|
Was it LULZSEC?
 ugh sorry that was dumb 
|
|||
|
|||
|
MaxSouth
Posts: 1374 |
|
||
|
Thanks everyone at ANN for trying to solve the problem.
However, with moving site from one provider to another problems are not gone. Even after the middle of August the download time of pages is barely acceptable, and more than once I received "Internal error 500" messages. I had very little time this month, and because of these slowdowns and errors I could not read the site for almost all of this time. I mean that I could, if I was waiting for every page, as slow as it is, to load, but I had time only to quickly check the news. Every time, after seeing that I will have to wait, I only could go away. I have more of free time only right now, and will browse the site even if it is slow (and it is; thankfully, as of now, at least there is no internal server error). Is there plan/roadmap on the matter of expanding servers processing capacities? I suspect the culprit are not PHP engine servers, but (My)SQL (PostgreSQL) engine servers. PHP scripts seem to have awful lot of time to wait for when "query" commands return result for PHP servers to build pages and send them to site's visitors. Edit: obviously, the problem has relation to peak load management, since the site, in my experience, works that bad during peak loads. This month I could only visit ANN in that kind of time. |
|||
|
|||
|
Shiroi Hane
Encyclopedia Editor
 Posts: 7584 Location: Wales |
|
||
|
There are a few relevant tweets on Chris (Tempest's) Twitter
https://twitter.com/ann_ed |
|||
|
|||
|
vashna
Posts: 1313 |
|
||
|
If I understand this right, the new server configuration uses names borrowed from Fujishima Kosuke's Oh My Goddess! series. If I am correct in that, it is the most awesome network naming scheme I've ever seen
|
|||
|
|||
|
Shiroi Hane
Encyclopedia Editor
Posts: 7584 Location: Wales |
|
||
|
This is not a new thing - they've always had those names
animenewsnetwork.com/ann-needs-new-hardware animenewsnetwork.com/survey/141/result animenewsnetwork.com/bbs/phpBB2/viewtopic.php?t=43046 |
|||
|
|||
|
vashna
Posts: 1313 |
|
||
|
Oh wow am I out of the loop! I apologize for that, though I must say that I love this place even more now!
|
|||
|
|||
|
Shiroi Hane
Encyclopedia Editor
Posts: 7584 Location: Wales |
|
||
|
It's not something you're expected to know - ideally you shouldn't need to
|
|||
|
|||
chefneer
 Posts: 1686 Location: Fort Worth, Texas |
|
||
|
Chris has been talking about possibly establishing a satelite server location as backup. It seems to me that if that were to happen it would be appropriate to name them after the Goddesses respective angels: Holy Bell for Bel, World of Elegance for Urd, and Noble Scarlet for Skuld. Just thought I'd throw that out there!
|
|||
|
|||
|
Teriyaki Terrier
Posts: 5689 |
|
||
|
Shiroi Hane: For several years now, I've noticed the word urd at the bottom on the ANN main page and it's something anyone could technically find, it would just take a little bit of looking around.
|
|||
|
|||
|
vashna
Posts: 1313 |
|
||
|
I've seen "@skuld" the whole time I've been here, but I've always assumed it was a pen name of the web designer or something similar. I feel like a rube now
|
|||
|
|||
|
MaxSouth
Posts: 1374 |
|
||
|
Thanks for the link to Christopher's Twitter messages.
Besides MySQL engine tuning, as well as some tables' optimizations, another approach can be used: in addition and/or instead of paying for additional MySQL servers for bigger loads/scalability, ANN's database structure might decrease the load with allowing much bigger redundancy than what is usually considered in typical theory and practice of relational databases management. This approach became actual in the recent years since giant-volume HDDs are super cheap these days. What do I mean? Problem: Lets take an encyclopaedia's page: to show it to visitor, the corresponding PHP script has to initiate either significant amount of SQL queries, or small amount of queries with complex multi-table selection/filtering rules. The problem is not with the sheer amount of data that has to be received for the page building process from the DB, but with the quantity of tables within the information is stored. Thus either of these two mentioned variants of queries seriously load MySQL server since it has to access huge number of tables to harvest data for even single page view. Solution: Some of these database tables can be actually joined into new, additional redundant tables in a very specific and optimal way, related to the main ID of the encyclopaedia entry. This approach would require significant space/volume redundancy, since currently existing tables are not meant to be deprecated or changed structurally in any way (needed for the principle of this approach, as well as for safety and reliability reasons), but it might dramatically shorten response time from MySQL servers, since the quantity of tables MySQL server has to look at to show an encyclopaedia entry will be many times lower. Cautions: There are burdens, though, besides space/volume issue (which is very cheap to solve now): synchronization. When the database is updated, besides the need to do it simultaneously among multiple copies of the database (if several SQL servers used to run ANN for scalability/load handling), the synchronization would also demand to be done within DB itself -- as was said above, besides currently existing tables, which do not go anywhere, the data has to be also pushed to newly created "redundant" tables. The proposed solution will dramatically increase load on MySQL servers during update procedures. However, if the quantity of such updates compared to quantity of visitors' views, overall balance of load will be still hugely in favour of this solution. Also, in some cases this solution has to expand use of "transactions" method, which does not apply any changes to any table unless absolutely all of tables proved to be successfully "updatable". This method increases load on MySQL servers, since it has to lock significant amount resources to make this operation reversible in case of update failure -- which is whole point of "transaction" concept. Scalability: Once this redundancy method will be tried out on some sort of pages (I took encyclopaedia as example; the method can be initially started with something else instead), it can be replicated to other types of pages with less effort due to some experience in this process will be already gained. |
|||
|
|||
 |
All times are GMT - 5 Hours |
|
|
|
Powered by phpBB © 2001, 2005 phpBB Group