NWS forecast issues

Internet Creating Weather Web Sites
1

Is anyone else having issues with the NWS forecast not updating??? It’s been dragging my site down for a couple of weeks now…the “fetch” script even proves it…the forecast right now is stuck on the 3 am release and when I click the link to open the NOAA-NWS site, it opens a current and up to date forecast…any ideas…here’s what fetch returned…My site is linked with the globe

HTTP Fetch Load Time Tester
check-fetch-times.php Version 1.02 - 19-Sep-2008

Included Settings.php time=0.001 secs.

–checking NWS Forecast URL –
URL: http://forecast.weather.gov/MapClick.php?CityName=College+Park&state=MD&site=LWX&textField1=38.9961&textField2=-76.9348&e=1&TextType=2
GET /MapClick.php?CityName=College+Park&state=MD&site=LWX&textField1=38.9961&textField2=-76.9348&e=1&TextType=2 HTTP/1.1
Host: forecast.weather.gov Port: 80 IP=forecast.weather.gov
Network error: (-1079633560)
HTTP stats: dns=10.001 conn=20.001 put=n/a get( blocks)=n/a close=n/a total=30.002 secs
fetch function elapsed= 30 secs.
RC=, bytes=0

Headers returned:

–end NWS Forecast URL check –

–checking NWS Warning Zone RSS Feed –
URL: http://www.weather.gov/alerts/wwarssget.php?zone=MDZ013
GET /alerts/wwarssget.php?zone=MDZ013 HTTP/1.1
Host: www.weather.gov Port: 80 IP=www.weather.gov
HTTP stats: dns=10.000 conn=6.179 put=0.000 get(38 blocks)=0.290 close=0.000 total=16.469 secs
fetch function elapsed= 16 secs.
RC=200 OK, bytes=3666
–end NWS Warning Zone RSS Feed check –

Total time taken = -1277744596.779 secs.
Elapsed 46 seconds.

PHP Version 5.0.5
Memory post_max_size 24M bytes.

2

Hi Wess,

Your webserver is having a DNS issue doing the lookup of forecast.weather.gov and that’s the cause of the slow response. Then the additional info of IP=forecast.weather.gov (instead of an actual IP address) shows that the DNS lookup was unsuccessful, so it’s no surprise that the connect time (conn= ) is also very slow, and the connection actually failed.

A 10 second DNS lookup time is very anomalous … you should contact your webhoster and open a trouble ticket with them.
Tell them the shared server at voyager.emacolet.com is having a DNS resolver setup problem (likely unable to connect with an upstream resolver).

Best regards,
Ken

3

Ken I believe you helped me with this exact problem a good while back, I dug through all of my old e mails with you and wasn’t able to find what you had suggested, but whatever recommendations you offered with regards to webhost settings, fixed the problem before. I DO know he has changed his DNS a little while back, and he also doesn’t remember what you asked for him to change…we do both remember the situation but not the solution. He insists his server is working properly and configured properly, and that my weather site is the only one having any issues, hence my asking here if others were experiencing an issue as well…By any chance do you remember what changes we asked my webhost to make?

4

Sure, here’s the mail we’d exchanged back in 2008

Hi Wess and Pete!

I’ve done a mod to the diagnostic script and think I’ve found the issue … it looks like the DNS resolver for the webserver is taking a long time to return for a gethostbyname() lookup and that is causing the PHP page to be slow.

On Wess’s server it takes between 4 and 5 seconds for the gethostbyname() to return with the ip address, while on other servers, that process takes < 0.1 seconds).

See: http://www.wessb.com/weather/check-fetch-times.php (look at the dns= times for info) v.s.
http://saratoga-weather.org/template/WD-USA/check-fetch-times.php

You can see the source for either script by including ?sce=view in the URL.

Pete, would you mind checking the DNS configuration for the server that Wess is on? There may be an upstream resolver/forwarder that is running very slow.

Thanks, and best regards,
Ken

Wess Breeden wrote:

Hey Ken…sorry to bother you again, nut I am involved in conversations with my host right now, and if you wouldn’t terribly mind maybe you can drop him an email if you think you cann add anything to this conversation…I will paste the email exchange here.

1st reply from Pete:
It absolutely amazes me how fast people point fingers. The ONLY PHP application that runs slow on this server just happens to be WD. There are no CPU hogs on this server. It runs 99% idle most times. The server is a Quad Processor duel core 3ghz processors. Even on a bad day they don’t run slow. Plenty of swap space and I have even increased the amount of memory PHP is allowed to use 256 M. This application still take 11 seconds to load. Not that 11 seconds is a bad thing.

If these people feel the PHP is not setup correctly then they need to tell me how this software feels it should be setup. However, I will not disable any feature that will leave the server vulnerable…

My response:
Pete, I aint tryin to start no s**t, was merely sharing with you what he said to me, and hoping that maybe that diagnostic thing might offer up some kind of clues, If you would like I will get you his email address and you can ask him if there are specifics that the scripts require. I certainly wouldn’t understand a word of what he would be saying anyway

And his 2nd reply:
All I am saying is if this software expects PHP to be setup in a specific manner than he needs to tell me what that manner is. All I see so far is him pointing fingers and not making any suggestions. As for that 11 second delay it is in HIS software.

Let them know that the PHP function gethostbyname() is having the problem. To diagnose it, have them log on to the server and run

nslookup forecast.weather.gov

On the host, it should show something like

(uiserver):usr:~ > nslookup forecast.weather.gov
Server: 172.19.254.4
Address: 172.19.254.4#53

Non-authoritative answer:
Name: forecast.weather.gov
Address: 204.227.127.200

(uiserver):usr:~ >

I’ll bet that the first resolver (172.19.254.4 in my case) will have a timeout of some kind and that’s why the DNS lookup is so slow for your website.

If it doesn’t immediately return a result (less than a second), then the server configuration (likely in the resolv.conf for DNS on the server) is probably pointing to one or more inaccessable DNS servers. When nslookup on the server runs fast, your site will likely be restored to function.

Best regards,
Ken

5

Thanks Ken…the info has been forwarded on.

6

Webhost insists every other site he checks resolves in .5 milliseconds, only the forecast.weather.gov is an issue. So I’m stuck I spose, could the software/sscript be making to many attempts to fast and get throttled back, causing a timeout?

7

Unlikely (on throttling back). If his

nslookup forecast.weather.gov

runs slowly, it’s likely that either:

  1. the caching DNS server on your webserver is having some issue or
  2. there is a firewall block somewhere preventing UDP 53 connection to the nameservers for weather.gov
  3. the nameserver entries in resolv.conf have a configuration that doesn’t point to a running(accessable) DNS server

It is anomalous for nslookup to succeed on some queries and fail on others … it’s a problem that needs to be fixed with
their server configuration (and/or firewall configuration).

Doing a quick check of your public DNS registration at http://www.checkdns.net/quickcheck.aspx?domain=www.wessb.com&detailed=1 shows:

CheckDNS.NET is asking root servers about authoritative NS for domain
Got DNS list for ‘wessb.com’ from c.gtld-servers.net or c.gtld-servers.net
Found NS record: ns1.emacolet.com[216.228.108.23], was resolved to IP address by c.gtld-servers.net
Found NS record: ns2.emacolet.com[216.228.108.24], was resolved to IP address by c.gtld-servers.net
Domain has 2 DNS server(s)

CheckDNS.NET is verifying if NS are alive
DNS server ns1.emacolet.com[216.228.108.23] is alive and authoritative for domain wessb.com
Error fetching SOA from ns2.emacolet.com [216.228.108.24], request timed out. Probably DNS server is offline.
1 server(s) are alive
DNS server ns2.emacolet.com failed and will be dropped from other tests

CheckDNS.NET checks if all NS have the same version
Your server has zone version 2008051101

so one of your primary nameservers is currently not accessable (ns2.emacolet.com) if that’s the first one in the resolv.conf nameserver, it could account for some of the timeout issue.

Having a nslookup on forecast.weather.gov is not a problem you (Wess) can fix … it’s something the server admin/network admin on your hoster need to address and fix. Generally, as a customer of a webhoster, you have the right to expect timely and error-free nslookup capability on the server you rent space on.

8

Thanks again Ken…I’ll make sure they get this info. I did see in doing an ns lookup that NS1 was getting through and NS2 timed out, so we are both getting the same results, yours obviously was more informative.