Ewok - and problem with support Re: slowdown

[jimnyc]

I've been having a recurring issue for about a month now with my site on Ewok. At least 3 times per day my site slows down to the point to where it becomes unbearable. This issue has been reported by many members of my site via email. I have had said users run diagnostics including tracert to see where the issue lies. For example, here is a tracert from when I had the issue just a short while ago:

Tracing route to debatepolicy.com [69.73.181.50]
over a maximum of 30 hops:

1 <1 ms <1 ms <1 ms 192.168.2.1
2 7 ms 5 ms 5 ms 10.120.0.1
3 6 ms 7 ms 7 ms dstswr2-vlan2.rh.mmrnny.cv.net [67.83.229.162]
4 * * * Request timed out.
5 8 ms 7 ms 7 ms rtr4-tg10-2.wan.whplny.cv.net [64.15.8.29]
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 42 ms 44 ms 44 ms atl-bb1-link.telia.net [80.91.251.86]
10 27 ms 26 ms 25 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
11 82 ms 217 ms 40 ms atl-core-g-g1-6.gnax.net [63.247.69.178]
12 28 ms 27 ms 25 ms 209.51.131.90
13 198 ms 199 ms 200 ms ewok.nocdirect.com [69.73.181.50]

Trace complete.

As you can see, all the request times are within spec until it actually reaches the server, where the requests jump to 200ms. It has spiked much higher in the past. I have opened quite a few tickets in response to this and am unhappy with the last few replies. Here is a reply from "Steve" just a short while ago"

We have looked into the tracert result you provided and it is clearly showing that the problem is there with your local internet.As you may see timeouts are at 4,6,7 and 8th hop which is very above our network.So please provide this tracert result to your ISP to look further into your issue.However we have also performed tracerts from different locations and these are showing no timeouts.So please provide this tracert result to your internet service provider.

I am very confused with his response as I was to believe the reason said hops didn't give results was because they were simply routers configured not to respond to ICMP Ping requests but Steve is insistent that my issue lies with my local connection to my provider.

Again, MANY users of my site have provided me with tracert results from around the country and all results are similar - decent speeds until it hits Ewok and then the speed spikes. I have used no less than 5 independent remote tracert tools on the internet and all give the same results (minus the supposed bad hops of course). I have linked to, showed the results and given screen shots to support - but Steve still responds that the issue is with hops 4,6,7,8.

I went further to install a top notch remote monitoring tool on a different server, which tests at specified intervals. Earlier today, the requests were all between 20-30ms until about an hour ago, where once again the requests to Ewok jumped above 200ms. Whether a tracert or a simple ping, the results are the same. Yet Steve came back yet again claiming the issue is with my ISP and to contact them.

To summarize: My users all report issues and provide proof of said issues. My remote tools on websites report latency issues with Ewok. My remote monitoring tool reports the spikes on Ewok. But I can't get anywhere with support other than the issue is with my local ISP.

Of course when I run the tests now it is normal, but this goes on and off several times per day. Prior tickets regarding this issue, not handled by Steve, has support telling me the issue was resolved and the server was experiencing issues and will be monitored in the future. But now I'm hearing it's an issue only on my end.

I am looking for input from others regarding my tracert results and what I've been told about the hops that didn't respond at all, and am also hoping a supervisor will see this post and offer additional assistance.

Thanks in advance to anyone who can help!

Jim

[Ron]

Point them to hop 13 in your email, and send along the salient parts of this post... the fact that you believe your ISP blocks ping requests, the fact that most of the time ewok is returning 30 ms, and if you can, deliver the traceroutes or timings from the other monitoring service.... even better is if the monitoring service spikes are at the same time as your traceroutes.

Be nice! At first glance I thought the exact same thing as the tech!!

[jimnyc]

Point them to hop 13 in your email, and send along the salient parts of this post... the fact that you believe your ISP blocks ping requests, the fact that most of the time ewok is returning 30 ms, and if you can, deliver the traceroutes or timings from the other monitoring service.... even better is if the monitoring service spikes are at the same time as your traceroutes.

Be nice! At first glance I thought the exact same thing as the tech!!

Thanks for the advice, Ron!

I did in fact point out hop 13 multiple times in my LONG support ticket, but that has yet to be responded to. First I was told it was my ISP, then I was told last night it was a dos attack, then again today it's back to my ISP. I have given MANY tracert results, multiple links to sites giving similar results running remote tracert, screenshots of all the above, as well as screenshots from the remote monitoring program I installed an a different server.

I've been nothing short of polite with everyone throughout and always have been. My strongest worded statement thus far has been politely asking "with all due respect, I request that my ticket be escalated to a supervisor to be looked at".

My ticket has in fact been updated that it has been sent to a senior admin, so hopefully I'll see positive results before long. It's just very frustrating when you not only have server issues, but you also take so much time to be as thorough as possible in providing the most detail available to show where the problem lies. Then you get a reply ignoring all the time you took and it simply points out the hops that timed out because of their configuration to ignore the ping requests.

Thanks again, Ron!

[Ron]

I know what you mean... there are so many techs, you can never guess which one will want what info! Sometime you jsut have to be persistent and restate the problem from a slightly different angle.

Then again, sometimes I've just been flat wrong, and they are the ones who have been patient in trying to get me to understand what an idiot I am.

[jimnyc]

I know what you mean... there are so many techs, you can never guess which one will want what info! Sometime you jsut have to be persistent and restate the problem from a slightly different angle.

Then again, sometimes I've just been flat wrong, and they are the ones who have been patient in trying to get me to understand what an idiot I am.

Admittedly, I've been there before too! LOL That's why I always remain polite and humble, I've been on the wrong end on many occasions! I once opened a ticket for slowness when I forgot I had my browser set to go through a proxy server! Luckily I remembered quickly and closed my ticket before I made a fool of myself!

Thanks again, Ron!

[jimnyc]

Unfortunately, I have received a similar reply from the senior admin at Jaguar:

This is the last traceroute you provided:

3 6 ms 7 ms 7 ms dstswr2-vlan2.rh.mmrnny.cv.net [67.83.229.162]
4 * * * Request timed out.
5 8 ms 7 ms 7 ms rtr4-tg10-2.wan.whplny.cv.net [64.15.8.29]
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 42 ms 44 ms 44 ms atl-bb1-link.telia.net [80.91.251.86]

which is clearly showing packet lost on several hops on your ISP end. Please provide us your IP address by visiting this page: www.myipaddress.com so we can take a reverse traceroute.

Can someone please correct me if I'm wrong from what I learned over the years, and have been told by some high level techs in the industry - that some routers are purposely configured to ignore ping requests, and this is NOT indicative of packet loss?

For example, here is a tracert to another server at Jaguar that I utilize, that is getting perfect response times and I have no complaints at all - and the very same routers give the very same responses.

3 7 ms 8 ms 7 ms dstswr1-vlan2.rh.mmrnny.cv.net [67.83.229.161]
4 * * * Request timed out.
5 6 ms 9 ms 8 ms rtr4-tg11-2.wan.whplny.cv.net [64.15.8.25]
6 * * * Request timed out.
7 * * * Request timed out.
8 * * * Request timed out.
9 43 ms 59 ms 44 ms atl-bb1-link.telia.net [80.91.251.86]
10 29 ms 28 ms 32 ms globalnet-103907-atl-bb1.c.telia.net [213.248.90
.54]
11 29 ms 27 ms 27 ms atl-core-g-g1-6.gnax.net [63.247.69.178]
12 29 ms 29 ms 66 ms 209.51.131.90
13 28 ms 32 ms 28 ms 69.73.182.45
14 28 ms 29 ms 27 ms 69.73.183.192

Trace complete.