Dumb question, but I am a newbie after all. What does the acronym "NOC" stand for?

Network Operations Center

Nice Orange Coat

Never Own Compaq

Funny. I'm a newbie, but not THAT green behind the ears. Can you give me some recognizable names of different Network Operations Centers? I read on another post that my hosting provider has had issues with their "NOC" and I'm wondering if that is why my site (and my host's site) has had so many problems with downtime and slow response time over the past couple of months. My site is hosted through Jatol. Anyone know who/what/where is their Network Operation Center? I just found out today they are somehow connected to DV2. Is DV2 perhaps where the issue lies?

NOC normally means data center and alot of hosts like to portray themselves as actually being the NOC. That I don't agree with but that's another issue.

So, your host's NOC is indeed DV2 if that's where their servers are. I haven't heard about alot of problems with DV2 though and they have a decent facility. Also, alot of hosts will blame any problems on the data center, the network - anything apart themselves which I also don't agree with. :D

Just trying to figure out what's the root cause for the recent slow response times, timeouts, and downtime on my site. I don't want to blame my hosting provider if they are not the ones at fault. After all, when my site is down, I notice that their site is down. So we're all suffering with this issue the past few months.

Anyone have any ideas? I noticed this is a sporatic problem -- happens a few times a week for the past couple of months. Never happened before then.

Well, they may only have one server and you could be on the same server as their site. If that server has problems then of course your site would be affected at the same time their's is. Try doing a tracert at the times of the slowdowns to discern if there are network issues or it's just the server slowing down.

I actually tried doing that today (for the first time), however, I'm not sure how to interpret the data. I'm really new to this whole thing.

The numbers that it shows is the amount of time it takes a packet of data to go from you to the website and back to you in miliseconds.

I usually like anything under 40ms.

You know, I may not have done that correctly. I went to: http://www.tracert.com/cgi-bin/trace.pl and typed in one of the server IPs where my site resides. It required that I select one of the traceroute servers listed. I guess as long as all the responses came back under 40ms it's okay?

Sorry to ask such basic questions, but I have no formal technical training on any of this stuff. I've been learning everything by "doing" (trial and error) and by reading info in journals and on sites such as this one.

The numbers shown in milliseconds will depend on how far away from the server you are. The big thing is to check if those numbers jump to a much higher level anywhere along the way - which would indicate a traffic issue.

If that's clear and the server itself appears to be slow to respond it may indicate overloading or a rouge script onboard.

Greg Moore

Well, the tracert will show you your route to the server. Here's an example trace to DV2 (last few hops only):

8 atlnga6lce1-cuttingedge-atm.wcg.net (64.200.126.70) 59.878 ms 59.740 ms 60.090 ms
9 gige.williams-atl.dv2.net (209.51.130.33) 60.514 ms 60.250 ms 59.860 ms
10 atl-core-a.dv2.net (209.51.134.154) 172.849 ms 60.149 ms 60.952 ms
11 209.51.157.228 (209.51.157.228) 62.187 ms 61.788 ms 61.374 ms

See the time displayed in ms (milliseconds)? That's the amount of time it takes to get to each hop. The last 3 hops are at DV2 which is why I'm just showing you this. Now this is a pretty decent route. All hops are a consistent 60ms until they hit the server. If the data center has having internal issues it may look something like this:

8 atlnga6lce1-cuttingedge-atm.wcg.net (64.200.126.70) 59.878 ms 59.740 ms 60.090 ms
9 gige.williams-atl.dv2.net (209.51.130.33) 60.514 ms 60.250 ms 59.860 ms
10 atl-core-a.dv2.net (209.51.134.154) 172.849 ms 60.149 ms 200.952 ms
11 209.51.157.228 (209.51.157.228) 62.187 ms 61.788 ms 681.374 ms
This would be indicative of overloaded pipes, extremely high traffic, DoS - all of which will slow your site down.

Also, you may see something like this:

8 atlnga6lce1-cuttingedge-atm.wcg.net (64.200.126.70) 59.878 ms 59.740 ms 60.090 ms
9 gige.williams-atl.dv2.net (209.51.130.33) 60.514 ms 60.250 ms 59.860 ms
10 ***
11 ***

If you see that, then the server could be having issues or it could be a switch at DV2. You could only know if you were familiar with the route through DV2 to see if the problem is at the server or a little further back.

You should also check every hop from you to the server. Perhaps it isn't DV2 at all and perhaps it isn't the server. Could be a bandwidth provider having issues at some node or peering point.

Information overload. :)

Originally posted by webrookie
You know, I may not have done that correctly. I went to: http://www.tracert.com/cgi-bin/trace.pl and typed in one of the server IPs where my site resides. It required that I select one of the traceroute servers listed. I guess as long as all the responses came back under 40ms it's okay?

Sorry to ask such basic questions, but I have no formal technical training on any of this stuff. I've been learning everything by "doing" (trial and error) and by reading info in journals and on sites such as this one.
You would need to do a tracert from your computer to your site. The tracert site is good for confirming that the problem lies just not with you. But at that site you choose where to tracert from. To start pinpointing your problem, you want to make sure that the issue is not with your particular route - i.e. a bandwidth provider having difficulties.