In the last few days, the TB server has been very slow to respond, occasionally causing my browser to time out with Page Unavailable. Is this a transient condition, or a significant problem that's being worked?
As the resident TB server geek, I can tell you that it is not a bad server. I also do not see an issue with Trainboard.com itself. We can predict the slowness within a minute or two, and I plan to put more tracking items in place to find out the root cause. John
Thanks. Initially I thought was my ISP, but it became obvious the delays were only with the TB site, and then only about 50% of the time. Let me know if I can help some way.
Once in a while now it jumps right in, connects fine. However: When you can hit refresh, or try to open a photo in new tab, or whatever, and you finally leave, go out and move vehicles around in the driveway and street before it finally connects, there is a problem. After I came back and it had finally connected, I refreshed both tabs, separate times, two minutes. In these days of MS 10, two minute connect time is MS 95 time frame. And yet, right now, it's acceptable. Both FF and a test on IE, same. Dave
I am rebuilding apache on the server today. It looks like the new forum software may need se server tweeks
Yes, not fixed yet; but the reboot has seemed to improve things. John is working hard to get to the bottom of things.
Worked well all afternoon until just now. Two and a half minutes, whirling circle of death before the tabs showed where we were going, finally about three minute mark they started resolving. Now I send and wait.
Dave, 60 years ago I equated delays such as you describe to a '54 Buick Dynaflow on a cold winter morning in New Hampshire. Start the car, put it in Drive, set a brick on the accelerator, go inside for a second cup of coffee, come back out as the car was finally starting to move. Bremner, is there a way for you to see what may be running in the background on the server? I often have the same problem when a third-party backup system runs periodically. I quickly execute Task Manager and see that instruction cycles are being "stolen", but there won't be an identifier showing what system is stealing those cycles. Unfortunately I don't have access to a deep level trace package that logs cycle stealing since I retired. Dave, do you have access to a tracing/logging system?
I have traceroute: hop rtt rtt rtt ip address fully qualified domain name 1 0 0 0 208.101.16.73 208.101.16.73-static.reverse.softlayer.com 2 0 0 0 66.228.118.157 ae11.dar02.sr01.dal01.networklayer.com 3 0 0 0 173.192.18.252 ae14.bbr01.eq01.dal03.networklayer.com 4 * * * 5 31 31 40 97.74.253.94 ip-97-74-253-94.ip.secureserver.net 6 31 31 31 97.74.253.94 ip-97-74-253-94.ip.secureserver.net 7 33 33 34 97.74.253.98 ip-97-74-253-98.ip.secureserver.net 8 30 30 30 208.109.113.174 ip-208-109-113-174.ip.secureserver.net 9 33 33 33 173.201.188.174 ip-173-201-188-174.ip.secureserver.net Trace on the 173 gives identical results. With all the un-stopped spam, scam and phishing coming through softlayer and wildwestdomains, almost doesn't surprise me there can be bottlenecks getting all the spam sent out before regular traffic.
Ok, 2 different apache builds. Enabled suPHP. Modified permissions. Modified users. The issue is there is a lot of traffic on httpd and I have to wait for enough data to find out the root cause