Site problems
Last night and tonight have been really whacky for me. Browsing is mostly ok, but I hit points where posting is near impossible. Is it because of the increased mafia load (Though there never seems to be more than 10ish) or is it on my end maybe? It's happening both at home, and at the school here. I haven't seen anyone else comment on it so I'm worried it's something local.
Vex
13 years ago
I haven't been experiencing any problem :/
Eve
13 years ago
It totally wonked out on me when Roz posted the roles and again after the kill. Ten mins prior to that I had been browsing around the whole forum no prob, but it would suddenly start hanging. So I don't think it's just you hon.
ROzbeans
13 years ago
It's been lagging for me - I'm not sure the extra hits from the mafia game would tax this heavily on the new server, but I can look into it with fatcow and see. /shrug Sorry for the problems and confusion.
Vulash
13 years ago
I'm sure it'll be fine until after Mafia so you don't have something else to worry about :P I was just freaking out last night because I was all into clueing
pharren
13 years ago
It's been bugging out for me for a few days also. Not only lag, but TOTAL WEBSITE MELTDOWN with 404 errors and such, just trying to go to the main forum page.
ROzbeans
13 years ago
Hello,
Thank you for contacting Support.
We apologize for any inconvenience this may have caused you. I checked your website at: www.theangrycrayon.com and it is working fine. I have not experienced any slowness issue. In order to investigate further on your issue, please get back to us with the following information:
1) The browser type and its version which you are using.
2) Is there any specific time period during which you are unable to access your website?
3) The geographical location from where the website is inaccessible and the ISP you are using.
Gimmee that info.
Thank you for contacting Support.
We apologize for any inconvenience this may have caused you. I checked your website at: www.theangrycrayon.com and it is working fine. I have not experienced any slowness issue. In order to investigate further on your issue, please get back to us with the following information:
1) The browser type and its version which you are using.
2) Is there any specific time period during which you are unable to access your website?
3) The geographical location from where the website is inaccessible and the ISP you are using.
Gimmee that info.
Gongaa
13 years ago
1) Firefox 3.5.10 on Fedora 12
2) from about about 08:00 to 18:00 CEDT (so like... 11pm the day before to 9am today on PDT)
3) Northrhine-Westfalia / Ruhr Metropolis in Germany. ISP is Arcor.
Having hardcore problems trying to post anything, and a lot of the time it's like stylesheets aren't being loaded when I'm just trying to read a thread (assuming I don't get a 500 or just plain old time out first). This stopped happening for me about an hour ago.
Here's a traceroute from me to here:
2) from about about 08:00 to 18:00 CEDT (so like... 11pm the day before to 9am today on PDT)
3) Northrhine-Westfalia / Ruhr Metropolis in Germany. ISP is Arcor.
Having hardcore problems trying to post anything, and a lot of the time it's like stylesheets aren't being loaded when I'm just trying to read a thread (assuming I don't get a 500 or just plain old time out first). This stopped happening for me about an hour ago.
Here's a traceroute from me to here:
[walrus@walrus-desktop ~]$ traceroute www.theangrycrayon.com
traceroute to www.theangrycrayon.com (65.254.248.142), 30 hops max, 60 byte packets
1 WL.domain.com (192.168.2.1) 1.134 ms 1.198 ms 1.345 ms
2 dslb-188-100-064-001.pools.arcor-ip.net (188.100.64.1) 6.717 ms 7.924 ms 9.403 ms
3 92.79.251.217 (92.79.251.217) 18.180 ms 18.220 ms 18.365 ms
4 88.79.22.81 (88.79.22.81) 16.772 ms 17.905 ms 18.581 ms
5 92.79.212.145 (92.79.212.145) 19.889 ms 21.351 ms 22.939 ms
6 92.79.213.122 (92.79.213.122) 31.217 ms 13.092 ms 14.086 ms
7 xe-1-2-0.mpr1.fra4.de.above.net (80.81.194.26) 22.418 ms 23.838 ms 25.507 ms
8 xe-2-3-0.mpr2.ams5.nl.above.net (64.125.31.238) 29.526 ms 29.652 ms 30.771 ms
9 so-2-1-0.mpr2.lga5.us.above.net (64.125.31.182) 120.808 ms 121.988 ms 124.353 ms
10 so-0-0-0.mpr1.lga5.us.above.net (64.125.27.237) 120.562 ms 122.075 ms 123.562 ms
11 xe-1-1-0.mpr3.bos2.us.above.net (64.125.25.41) 113.622 ms 115.752 ms 116.638 ms
12 reserved.above.net (208.184.39.37) 112.215 ms 113.810 ms 114.750 ms
13 216.75.151.9 (216.75.151.9) 117.041 ms 118.650 ms 119.913 ms
14 207.180.56.2 (207.180.56.2) 125.078 ms 117.390 ms 117.488 ms
15 65-254-248-142.yourhostingaccount.com (65.254.248.142) 109.415 ms 111.545 ms 111.977 ms
ROzbeans
13 years ago
After stalking you on facebook =D I saw you were in germany. Would have helped if I looked at your location under your avatar here, too. =x I put that down in my help ticket to fatcow. I think it might be the amount of hits/people have surged and that's what is causing the issue, but I'll let y'all know what fatcow says because they said they couldn't see any other type of issue and couldn't get it to lag out.
ROzbeans
13 years ago
I looked at the usage for the site. It's doubled since the 4th. lol
Gongaa
13 years ago
I think Vulash said it best:
I hope everything gets sorted out without too much stress on your end. You've gotta be strapped for time right now.
ROzbeans;97957
After stalking you on facebook =D I saw you were in germany. Would have helped if I looked at your location under your avatar here, too. =x
I think Vulash said it best:
Vulash;97893
huhuhu
I hope everything gets sorted out without too much stress on your end. You've gotta be strapped for time right now.
ROzbeans
13 years ago
I almost sat on my son who dived into my computer chair seat. You tell me lol
ROzbeans
13 years ago
They escalated the ticket. I don't even know why they even bother with a tier 1, they can never do ANYTHING. 24-48hrs before I hear anything else =/
ROzbeans
13 years ago
Hello,
The following is in regards to the issue you were having under ticket number 7235930. We do apologize about the inconvenience, and do appreciate your patience. I have checked he load on the server that you are running off of, and the load on the server is fine. I also checked the website and it is currently running fine as well. There are however peek times when others customers on the server may be pulling resources from the same container, which can cause some slowness. You would want to look into Optimizing the Database or you may also want to consider using Indexed Views for Denormalization.
When you have joins across multiple tables that do not change frequently, such as domain or lookup tables, you can define an indexed view for better performance. An indexed view is a view that is physically stored like a table. The indexed view is updated by SQL Server when any of the tables that the indexed view is based on are updated. This has the added benefit of pulling I/O away from the main tables and indexes.
If you have any further questions, please update the Support Console
Thank you,
Elijah M
Technical Specialist
Hmm. That means nothing to me, at least beyond the optimizing part. I'll do that.
The following is in regards to the issue you were having under ticket number 7235930. We do apologize about the inconvenience, and do appreciate your patience. I have checked he load on the server that you are running off of, and the load on the server is fine. I also checked the website and it is currently running fine as well. There are however peek times when others customers on the server may be pulling resources from the same container, which can cause some slowness. You would want to look into Optimizing the Database or you may also want to consider using Indexed Views for Denormalization.
When you have joins across multiple tables that do not change frequently, such as domain or lookup tables, you can define an indexed view for better performance. An indexed view is a view that is physically stored like a table. The indexed view is updated by SQL Server when any of the tables that the indexed view is based on are updated. This has the added benefit of pulling I/O away from the main tables and indexes.
If you have any further questions, please update the Support Console
Thank you,
Elijah M
Technical Specialist
Hmm. That means nothing to me, at least beyond the optimizing part. I'll do that.
Gongaa
13 years ago
I'm a device driver and embedded systems guy, not a DB admin/programmer, so if anyone wants to jump in and correct me, go for it.
Joins (matching up tables by cross reference) are generally the most computationally expensive DB operations you can do, so by creating an indexed view, you do some heavy lifting ahead of time by using some sort of heuristic to get data ready to serve (and apparently in this case store it in its own table), and the costs are amortized by slimming down the joins later. He specifically mentions joins across multiple tables because shit can get out of hand fast when you start chaining them together.
A rudimentary example would be the user info such as avatars etc. that appears with each post, and the content of the posts themselves. There's a table floating around somewhere that has columns for shit like user id, location, post count, etc, and another with columns for user id, post id, thread id the post belongs in, so when you open a thread, the DB goes in and cross references (or joins) those posts and users by the common attribute, user id. If this is stuff you already know, I'm sorry. Not trying to preach to the choir or be overbearing!
I guess we're posting a little more than usual with the mafia stuff, but man, it's only like 15 people MAX at once, and most of that is reading, so you're not altering the tables that much - so it's not like tables are permanently locked so the scheduler can go in and serialize everything. I guess that's why he mentioned denormalization, since that's just optimizing for reads. Still, it doesn't seem like that would be enough to cripple the boards like they were. And since you're using vBulletin, which isn't exactly a mom and pop outfit, it just seems kinda weird that the DB would be bogged down. I know sites with like 2k+ users on at once bitch about vBulletin and end up going in and having to hack it to pieces, but there's a lot of fingers and toes between 15 and 2k!
Indexed views would definitely reduce the time it takes to serve shit, but it's already really fast when things work so you'd barely notice it. On top of that, I'm guessing you'd have to alter some tables to get everything set to create them, and that could have some ugly side effects - so you'd have to first make backups etc. Not to mention that you'd probably have to press the pause button on the mafia game.
The real killer blow is that everything's working fine now, and the load certainly wasn't worse during the middle of the night in the US than it is now - but it was still bugging out for me here.
ROzbeans;97979
You would want to look into Optimizing the Database or you may also want to consider using Indexed Views for Denormalization.
When you have joins across multiple tables that do not change frequently, such as domain or lookup tables, you can define an indexed view for better performance. An indexed view is a view that is physically stored like a table. The indexed view is updated by SQL Server when any of the tables that the indexed view is based on are updated. This has the added benefit of pulling I/O away from the main tables and indexes.
I'm a device driver and embedded systems guy, not a DB admin/programmer, so if anyone wants to jump in and correct me, go for it.
Joins (matching up tables by cross reference) are generally the most computationally expensive DB operations you can do, so by creating an indexed view, you do some heavy lifting ahead of time by using some sort of heuristic to get data ready to serve (and apparently in this case store it in its own table), and the costs are amortized by slimming down the joins later. He specifically mentions joins across multiple tables because shit can get out of hand fast when you start chaining them together.
A rudimentary example would be the user info such as avatars etc. that appears with each post, and the content of the posts themselves. There's a table floating around somewhere that has columns for shit like user id, location, post count, etc, and another with columns for user id, post id, thread id the post belongs in, so when you open a thread, the DB goes in and cross references (or joins) those posts and users by the common attribute, user id. If this is stuff you already know, I'm sorry. Not trying to preach to the choir or be overbearing!
I guess we're posting a little more than usual with the mafia stuff, but man, it's only like 15 people MAX at once, and most of that is reading, so you're not altering the tables that much - so it's not like tables are permanently locked so the scheduler can go in and serialize everything. I guess that's why he mentioned denormalization, since that's just optimizing for reads. Still, it doesn't seem like that would be enough to cripple the boards like they were. And since you're using vBulletin, which isn't exactly a mom and pop outfit, it just seems kinda weird that the DB would be bogged down. I know sites with like 2k+ users on at once bitch about vBulletin and end up going in and having to hack it to pieces, but there's a lot of fingers and toes between 15 and 2k!
Indexed views would definitely reduce the time it takes to serve shit, but it's already really fast when things work so you'd barely notice it. On top of that, I'm guessing you'd have to alter some tables to get everything set to create them, and that could have some ugly side effects - so you'd have to first make backups etc. Not to mention that you'd probably have to press the pause button on the mafia game.
The real killer blow is that everything's working fine now, and the load certainly wasn't worse during the middle of the night in the US than it is now - but it was still bugging out for me here.
pharren
13 years ago
de <-- peek time
There are however peek times when others customers on the server may be pulling resources from the same container, which can cause some slowness.
de <-- peek time
Vulash
13 years ago
I'm not buying it - it's sporadic. It'll be hell for 20 minutes then fine 10 then hell again for 10 then fine an hour. Unless America is rushing the computer at one time and then all rushing to poop at one time I just don't see that being the problem. Then again I don't know dick about this stuff.
Gongaa
13 years ago
Sympathetic pooping.
Vulash;97995
I'm not buying it - it's sporadic. It'll be hell for 20 minutes then fine 10 then hell again for 10 then fine an hour. Unless America is rushing the computer at one time and then all rushing to poop at one time I just don't see that being the problem. Then again I don't know dick about this stuff.
Sympathetic pooping.
Wystro
13 years ago
I've had issues with TAC slowing down too...sometimes my browser will time out.
ROzbeans
13 years ago
Like I said, the usage has doubled, so I think all of us hanging out, refreshing the pages, could be part of the reason. I'm not a db/techie either, and I'm scared to optimize anything without Vex literally holding my hand, so I'll confer with her and see what else we can do.
pharren
13 years ago
Well, it's almost 3am EST, and between timeouts I'm getting this:
