I've been noticed that for the past few days now, maybe since Saturday, every night around 2 or 3am CDT, the Avsim forums seem to be unavailable or non-responsive and get the 503 error. Then after a while they come back up. At first I thought it was my computer but I have tried to access from other computers and even my phone during those times and the same thing happens.

 

Is there maintenance or something going on during those hours or is some idiot launching DDOS attacks at around the same time every night? 

The reason(s) are mission specific, I will PM you to shed some light, but yes this delay is planned but is highly necessary.

Any reason why this information is top secret. Fail to understand why a website would be down at all unless it was for essential maintenance. If your having to do this everyday then your fire fighting not fixing the route cause.

 

Apologies but I'm getting frustrated by how often I'm getting time outs and slow loads on this site.

 

Rant off

Now that the clocks have gone back here in the UK I'm less affected by this downtime but I suspect it's only temporary as the clocks go back in the US this weekend don't they?

 

I too am mystified why this downtime is so secret. It probably doesn't affect any US or Canadian members but is a pain on this side of the pond. It would be easier to understand why it is done if the reasons could be explained.

I don't know (or maybe better put; remember) what Chase might be alluding to, but I am here online most days at those times, and have not seen repeated outages during specific times, unless I implement them and that hasn't happened. We have no routine or CRON job that shuts the systems down or turns it off from the net. So, I do not know what you are experiencing. I do know that there are some seriously wonky DNS' out there that do some funny stuff along the way from a number of locations in Europe and Canada.

Tom, FYI: It's not just Europe and Canada that are affected. Every day, without fail, between (approximately) 0815-0845 UTC when I come to get onto Avsim, I also get a "503 Service unavailable" message.

Tom, FYI: It's not just Europe and Canada that are affected. Every day, without fail, between (approximately) 0815-0845 UTC when I come to get onto Avsim, I also get a "503 Service unavailable" messag

Tom, FYI: It's not just Europe and Canada that are affected. Every day, without fail, between (approximately) 0815-0845 UTC when I come to get onto Avsim, I also get a "503 Service unavailable" message.

 

All the usual questions then;

 

How long does it last?

What browser?

Have you done a TRACERT and PING during the outtage; especially a TRACERT?

Etc.

 

 

All the usual questions then;

 

From 0815-0845 UTC, however I will confirm the exact times later today

 

Firefox 25.0

 

I will do a TRACERT later today and will post the results here.

Can I suggest you use this link for testing.

 

This will show the test results from my test just made which was ok, push test now to test again.

http://tools.pingdom.com/fpt/#!/dBjnDy/http://forum.avsim.net/forum/121-ms-fsx-forum/

 

Click on advanced options and you can test from different locations.

Can I suggest you use this link for testing.

 

This will show the test results from my test just made which was ok, push test now to test again.

http://tools.pingdom.com/fpt/#!/dBjnDy/http://forum.avsim.net/forum/121-ms-fsx-forum/

 

Click on advanced options and you can test from different locations.

 

Yes, we use that test frequently. However what you used to perform the test was a PING. The results of that mean nothing except that there is a delay or not, getting to  and from the site and loading the page / elements. What needs to be used is TRACERT which will tell you not only if there is a delay, but where the delay or dropped packets is occurring.

From this morning:
Front Page
tracert avsim.com > tracert_avsim.txt

Tracing route to avsim.com [205.252.249.58]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  192.168.0.1
  2     *        *        *     Request timed out.
  3     9 ms     8 ms     9 ms  te-2-1-ur02.hammond.in.chicago.comcast.net [68.85.131.77]
  4    10 ms    10 ms    10 ms  te-0-4-0-2-ar01.area4.il.chicago.comcast.net [68.87.230.153]
  5    10 ms    11 ms    11 ms  he-3-8-0-0-cr01.350ecermak.il.ibone.comcast.net [68.86.90.49]
  6    11 ms    11 ms    11 ms  pos-1-2-0-0-pe01.350ecermak.il.ibone.comcast.net [68.86.86.78]
  7     8 ms     9 ms    11 ms  66.208.233.114
  8    35 ms    42 ms    44 ms  www.avsim.com [205.252.249.58]
Trace complete.

Forum Server
tracert forum.avsim.net > tracert_forum.avsim.net.txt

Tracing route to forum.avsim.net [205.252.89.43]
over a maximum of 30 hops:
  1    <1 ms    <1 ms    <1 ms  192.168.0.1 
  2     *        *        *     Request timed out.
  3     8 ms     8 ms     8 ms  te-2-1-ur02.hammond.in.chicago.comcast.net [68.85.131.77] 
  4    12 ms    14 ms    11 ms  te-1-9-0-0-ar01.area4.il.chicago.comcast.net [69.139.200.153] 
  5     9 ms    11 ms    10 ms  he-3-7-0-0-cr01.350ecermak.il.ibone.comcast.net [68.86.90.53] 
  6    13 ms    11 ms    11 ms  pos-0-13-0-0-pe01.350ecermak.il.ibone.comcast.net [68.86.87.250] 
  7    35 ms   237 ms    11 ms  66.208.233.114 
  8    40 ms    48 ms    37 ms  purple.servers.avsim.net [205.252.89.43] 
Trace complete.

That 66.208.233.114 IP is a COMCAST node. That 1/4 second delay is the reason why I want people to learn to read TRACERTS. Those delays happen before the packet even gets to us. Our response time, once we receive the packet, in this case, is 37 milliseconds. And Bill, worse is that you get a time out right at your first node (presumably your ISP) in both the TRACERT to avsim.com and forum.avsim.net.

The 2nd node is timing out because it's been set not to respond to pings, That is not a problem but it;s always gonna look like its timed out. Obviously its working or you wouldn't see anything downstream. 

 

Node 7 only has a long responce in one instance. I don't know how you can deduce anything from that whatsover. 

 

I suggested using pingdom as users, and myself, are reporting a http 593 error. This is generated by your web server (or load balancing system, cdn etc). If it were a network problem we would just get a time out but something at your end is generating and serving a bit of html saying 503.

 

 I'll dig deeper next time I see it for you but I think this is your backend system not coping somewhere. I'm guessing this normally the quietest time of day for your server so since it happens at the same time it does smell like a database maintenance job running.

 

 

The 2nd node is timing out because it's been set not to respond to pings, That is not a problem but it;s always gonna look like its timed out. Obviously its working or you wouldn't see anything downstream.

 

That was a TRACERT it was responding to in both cases, not a PING. In any case, yes, some servers are set not to respond and that is mostly likely the case.

 

 

I suggested using pingdom as users, and myself, are reporting a http 593 error. This is generated by your web server (or load balancing system, cdn etc). If it were a network problem we would just get a time out but something at your end is generating and serving a bit of html saying 503.

 

We use PINGDOM all the time, especially as the "server is too slow" complaints start to appear. As I said, there are some serious DNS' issues out there that do impact users and that system is how we found them.

 

If you can find something that allows us to focus in on this issue, then please by all means, let me know what you dig up.