Forum maintenance

[Conor Dary]

I can't say I blame you. It's hard to keep track of everything. Too many knuckleheads, including myself in the past, don't know the rules. Oh well...

[Daisy]

I suspect you'll suss out

Is this a Canadianism, I've never heard the USAsians use the phrase.

[Marlow]

I suspect you'll suss out

Is this a Canadianism, I've never heard the USAsians use the phrase.

I see it in the national media, but have rarely heard it in conversation. I used it in a work-related e-mail and got a 'huh?' response.

[Athleticsimaging]

The "view new posts" link is working but, the first time I clicked since the fix, I did get 2 messages "server chain certificate incomplete" or similar. Everything works if you click through. Just a heads up.

Have noticed that only the "view new posts" results in an "https:" along with the resulting errors, whereas being logged in automatically and selecting any individual forum does not because it is not a secure link.

Also, selecting a letter on the "Members" page results in

Code: Select all

Not Found

The requested URL /discussion/memberlist.php&first_char=p was not found on this server.

[bushop]

The added incentive for being conservative is that the moderators don't constantly have to be removing copyrighted material, since so many people appear completely clueless on that concept.

Being conservative is one thing and banning pictures altogether is another. The way it is now, the following wonderful thread would be impossible.
http://www.trackandfieldnews.com/discus ... irgin+rose

So we be clear: given the option between the (very) rare posting of "original" content and piracy (and the attendant risks that come with opeining the gates), I suspect you'll suss out the way this whole conversation is trending...

I think we'd all love to see those pics Mump Boy, would you share them with us?

Has a decision been made? Photos or no photos?

[guru]

Site dragging BIG TIME during today's evening session of indoor Worlds

[gh]

We're on it. But note that as of a few minutes ago, everything went back into glue mode

[Daisy]

Glue mode is an understatement. I guess one good thing is you are getting a lot of traffic. Is there any way to have extra bandwidth during the majors events?

[gh]

I'm not the technician, but traffic shouldn't be an issue; our peak this morning was only about 25% of what we have handled at record levels with little problem.

[guru]

Well FWIW, it's only been an issue this weekend during those evening sessions hours of Worlds

[gh]

That's true enough (and hopefully it's a good clue), but I'd note that yesterday evening when we had the NCAA up and running the traffic was about the same sans issue. At least none that I noticed, although I wasn't online as regularly as during the Worlds.

[Daisy]

I wonder if it's due to us all streaming the event at the same time as trying to use the site? So more a problem at our end rather at TFN's end? Did anyone try to use the messageboard when they were not streaming?

[Pego]

I wonder if it's due to us all streaming the event at the same time as trying to use the site? So more a problem at our end rather at TFN's end? Did anyone try to use the messageboard when they were not streaming?

I did. It was very slow. I don't think I ever observed relationship of slow site with traffic.

[Conor Dary]

Maybe there is a virus in the stream web site that attacks the link. Who knows but it seemed a bit dodgy. Especially the part about donating money. And then every so often it would go to some nutty ad.

[gh]

This morning seems better than the last two, but I note now that we've got 80-plus people on board things might be slowing down.

[pjmorse]

I share GH's suspicion that numbers of people on the site isn't entirely the issue. When we reach what GH calls "glue mode" the load, in technical terms, is not terribly high. I think there are other issues at play. Technical geekery follows.

"Load" in computer terms has a specific definition: the number of instructions waiting for the CPU. When the system is slowing down, I can log in and check the load, and the numbers aren't very scary. Any number under 1.00 is well within the capabilities of the server; over 1.00 starts to be noticeable, and over 10.00 is dramatic. I've seen 40s and 80s before, but only in meltdown situations.

I think what's really happening is that the server is being pushed into "swap". If you think of RAM as the number of things you can keep in your head, swap is what you write the other things down on. It's actually the system writing some RAM out to disk so it can use it elsewhere. When you go into swap, things really bog down, but if the system gets a little breathing space it may dig itself out. However, if it hits swap because of some system bug (e.g. a program gradually claiming more and more memory, but never releasing any) it will bog down until it crashes. This is why old Windows systems get slower and slower; the Registry, part of the operating system, gets bigger and bigger, using more and more memory over the months and years, until swap becomes more and more frequent.

On servers like this one, the culprit can be a specific web-server thread, or mail-filtering thread, which can hog a bunch of RAM for a few minutes or a few hours. Sometimes the thread needs to be killed to free up RAM; sometimes it just finishes its job and goes away, and nobody is the wiser as to what was going on.

One of the things I've been working on here and there over the last few weeks has been moving non-web-server tasks out of this system to reduce the number of moving parts and reduce the chances that, say, a rogue DNS query could bog down the whole system. The details are not really relevant to this forum. But I'm also trying to simplify the number and kinds of web server processes running in order to nail down which ones cause problems. It is a very haystack-like issue; there are at least four web applications running at any given time.

I've also been tweaking the actual server configuration in an effort to make pages load faster on your end - http://code.google.com/speed/page-speed ... intro.html gives a reasonable outline of the things I'm trying to address. I'm hopeful that this also helps the server handle more visitors before hitting swap.

[guru]

20-30 second load times are simply excruciating when trying to read/post during a bang-bang track meet. It's problem that needs to be remedied before outdoor NCAAs and the Trials.

[guru]

Busy night thanks to the Jamaican meet, and page loads slow again to a glacial 20+ seconds.

Ugh...

[notorious]

Busy night thanks to the Jamaican meet, and page loads slow again to a glacial 20+ seconds.

Ugh...

Meet is over and thus, page loads seem back to normal.

[guru]

Whatever the glitch is, if it's not fixed by the Trials(and probably NCAA's) this site is going to melt down.

[Grasshopper]

Whatever the glitch is, if it's not fixed by the Trials(and probably NCAA's) this site is going to melt down.

Those meets are likely to have functioning live-updates (I can't understand why a meet of the level and proclaimed significance as the Jamaican Invite did not), so not as many people will be constantly checking for those updates here.

[gh]

Busy night thanks to the Jamaican meet, and page loads slow again to a glacial 20+ seconds.

Ugh...

I wasn't around last night: I assume you're referring to our pages, not Jamaica's?

[guru]

Correct. I only referenced the Jamaican meet because that's what spiked the number of people on the forum.

[pjmorse]

I'm looking at a number of possible reasons for what gh calls "glue mode." The fact that there is more than one should tell you I'm not confident that any one of them will be a silver bullet.

I may ask for some testing assistance with one of them later this week.

[guru]

Just guessing here, but considering it's happened during popular live meets, I'm thinking it has to do not so much with a hundred or more people just being on the forum, but all those people refreshing constantly, and likely many simultaneously.

[pjmorse]

Guru, you do have a point. One of the issues I'm looking at is a very CPU-intensive task which is run by 'cron' daily; it happens to fall around midnight UTC, which is not really a great time for it. But that might not be the issue.

More to the point, I'm looking at caching for the whole site. I'll spare you my course material on network caching, which is desperately off-topic for this forum, and just say that caching works best in just the situation you describe, where the actual pages aren't changing frequently but a lot of users are hitting reload often.

I want to give this a beating before I serve the whole site this way, so here's your chance to give it a try. Next time you hit the forums, try starting at this URL:

http://www.trackandfieldnews.com:8088/discussion/

That's the cache, running on port 8088. Don't expect it to be faster at the moment, although that might be a pleasant bonus. What I want to know now is whether this makes anything break - does posting not work, do threads not update, do new threads show up significantly later than on the main site. (My guess is no; I'm posting through the cache right now. However, a lot of people find problems a lot faster than one can.)

If you try it and have problems, let me know what the problems are, and then just take the ':8088' part out of the URL and you'll be back on the un-cached site.

Eventually we'll switch the cache to handle all traffic and the 8088 port will be closed again.

[26mi235]

I get:
Unable to connect

[pjmorse]

I get:
Unable to connect

Hmm. Are you behind a corporate or school firewall, by any chance? Those often block high-numbered ports like this, which is not a bad idea. I'm unable to duplicate the issue here, using multiple browsers and computers (but from the same IP address).

[guru]

Works fine for me from my home computer

[EPelle]

Using the link through the 8088 port certainly gave the appearance that this site loaded faster than that to which I'd grown accustomed here. No discoverable issues/challenges with links.

[26mi235]

I get:
Unable to connect

Hmm. Are you behind a corporate or school firewall, by any chance? Those often block high-numbered ports like this, which is not a bad idea. I'm unable to duplicate the issue here, using multiple browsers and computers (but from the same IP address).

At Work

Home is in transition and I have to dig out my password which is on the old machine (power supply died) [just dug it out at work ]. I will test at home.

[pjmorse]

First: in response to a Doha-induced (we think) case of "glue mode", the cache is now in production. If you visit port 8088, you're looking at the uncached site. If you don't use a port number (which means the default, port 80) you'll get the cache. Again, let me know if you see issues, but the cache is very conservative and I doubt we'll see any.

Using the link through the 8088 port certainly gave the appearance that this site loaded faster than that to which I'd grown accustomed here. No discoverable issues/challenges with links.

"Gave the appearance" of loading faster is good. Odds are the caching of things like included Javascript, CSS, and images results in your browser having all the pieces it needs to render the page sooner. There's more to it than just generating the HTML.

[Grasshopper]

When trying to submit a post the site hangs and then goes to a dead screen. This is often leading to people refreshing their screen during the submit, causing multiple identical posts.

[pjmorse]

When trying to submit a post the site hangs and then goes to a dead screen. This is often leading to people refreshing their screen during the submit, causing multiple identical posts.

By "dead screen" I assume you mean a blank page. We just had a blink of some sort a few minutes ago which may have led to those hangs; we'll see if I get any issues posting this.

[tandfman]

By "dead screen" I assume you mean a blank page. We just had a blink of some sort a few minutes ago which may have led to those hangs; we'll see if I get any issues posting this.

The world is waiting for your report.