Well, no progress after more than 2 hours on the phone, and I am tired! They did run the tests as Ken suggested
You can have them refer to the network techs (instead of the server techs) by having 1st level tech support simply log on the webserver with SSH and in the console try:
wget -d weatheroffice.gc.ca -O tst.txt
traceroute weatheroffice.gc.ca
ping weatheroffice.gc.ca
try it several times and they should see the diagnostic messages and the output saved in txt.txt
That should allow them to properly research the connectivity issue without so much wasted effort. Unfortunately,
most hosters prohibit mere users from running traceroute or ping, so the system admin will have to do that.
and say they were successful, outbound connection were made, that they are not blocking... they no longer have the outbound issue so not a GoDaddy issue. Tech says he has had 3 Admins involved and that he has gone as high in support as possible. But I am not convinced of that!
Tech did make some changes to my php5.ini and now it is:
short_open_tag = off
max_execution_time = 300
memory_limit = 512M
upload_max_filesize = 256M
post_max_size = 256M
max_input_vars = 5000
wait_timeout = 300
Apparently my komokaweather.com uses 14.75 mg (he couldn't explain what that represents but that it is very large)
To my repeated comment that everything was fine as off Monday evening and why all of a sudden now 5 of my templates don't load or don't load properly and have similar issues, he would only say "they are not blocking outbound, and not a GoDaddy issue". On the logged errors he says the time out it is not at the GoDaddy server.
The only suggestion they have, other than for me to look at the pages content, is to move to a newer server (buy a newer plan) and c-panel which can use PHP 5.6.
Does anyone have any direct contact at GoDaddy that I can try to appeal to?
Paul
@PaulMy
In IT since 1968, with at least 10 years responsibillity for local and wide networking and application support for the largest companies, I want to add my remarks in defense of the support people. I also had to counter the effects of overloaded queues multiple times:
https://en.wikipedia.org/wiki/Queueing_theoryOften with performance problems the customer can not connect the cause = "a 'minor' change somewhere" with the results = "all sites down".
What customers did before the problems started is in their eyes so irrelevant compared to the problem that they do not accept that they themselves introduced the cause for the failure of their system.
The evening before the day all sites started to fail:
1. you installed new / updated versions of Meteotemplate and of ... and maybe ...
2. Probably you adjusted a cron-job or maybe two
And
3. You are running 2 heavy cron driven sites and multiple other sites on the same small Apache webserver shared by 1000 (normal number for a Godaddy host) domains.
4. Maybe one of these "other" sites were changed also?
I you are really 100% convinced that the cause for these problems is not in one of your changes for the last days, skip the rest of this post, PM me and I will delete this post.
To be honest, I am not convinced, as when I look to enormous amount of php scripts loaded, any webserver has to queue all requests (in multiple queues) and will handle them one at a time. Those scripts using only internal data will work OK. But scripts using external data will have to wait until it is their turn. Even if there were an error in the queue handling, it would occur on all sites sometimes. Not ALWAYS on your site within a few minutes of browsing.
Your response times are often good in the morning here in Europe, but always suddenly change to very bad.
When I am browsing either Saratoga and Leuven response is all OK. For minutes. External data is loaded and so on. And then suddenly total failure.
How come? Not because of other users in the middle of your night. Maybe a cron-job starting? Maybe a automatic backup every ** minutes?Some scripts loading external data seem to have no timeout set or the system setting is far to large. Example bloomSkyLatest.php: time-out after 120 seconds .
Maybe there are more of those scripts which are the cause?
And why do some scripts always fail on your site, but you are still loading them:
http://a.sitemeter.com/analytics.js Failed to load resource: the server responded with a status of 503 (Service Unavailable: Back-end server is at capacity)I still think the best way to go is: Test and Test and Test until you know what is happening and you can
prove what is the cause
1. Switch off all template sites => You do not need to un-install or remove them, rename the (folder and the) index.php only
2.
Switch off ALL cron-jobs 3. Test your
http://www.komokaweather.com/ site and the two other non-template sites.
3.
Remove all errors when there are errors on the console
4. Let Saratoga run as the first template and test also check-fetch-times.php
It that has timeout errors it is a GoDaddy problem for sure.
Check also if the cache is functional
Check for sites which maybe banned you are the IP address of your server
5. If Saratoga runs OK lets run Leuven, that template loads slightly more external data but needs no cron as the remaing two do.
Test with running Saratoga and Leuven and your Cumulus site and do all checks possible
6. If all that is Ok start Meteotemplate WITHOUT its cron-job
7. If that combination of three templates runs OK, start the cron-job for Meteotemplate.
and so on.
8. If one of those templates is causing problems, switch it off (including its cron-jobs) and continue with the others.
Your 7 websites of which 4 are templates with ALL possible pages and ALL automatic loads / cron-jobs / external data: that can probably not be handled by a 1000 sites shared server. At some point the server will collapse, maybe the required memory is higher than the allowed, maybe the queue to the outside world is to small.
But after
testing until the system fails
instead of talking about it, we know far better what the cause is then we do now.
And in this case I think this idiom is very relevant:
https://en.wikipedia.org/wiki/Straw_that_broke_the_camel%27s_backWim
