We now have avatars and more 'advanced' forum but wouldn't that put more stress on the servers?
If so and the server wont crash ect. They must have fixed the problem we had before and they should now put pending credit and results back up!
<a><img>[/url]
^ Click Here ^ ^ Click Here ^ ^ Click Here ^

> We now have avatars and more 'advanced' forum but wouldn't that put more
> stress on the servers?
> If so and the server wont crash ect. They must have fixed the problem we had
> before and they should now put pending credit and results back up!


I think this is a valid question. Everything in the forums hits the DB, I believe, and even stuff like the "unread" change means that the DB has got to be hit when a thread is displayed.

Rom, Paul, do these changes mean an increase in hit's on the DB?
How does it relate to the hits that would occur when a user looks for "prending credit"?


I await your response.....

Thanks in advance...

The amount of IO the boards generate is not significant compared to the other functions. Yes it does generate more hits to the DB but it would be a very small percentage and I wouldn't worry about it.
mostly_harmless

> The amount of IO the boards generate is not significant compared to the other
> functions. Yes it does generate more hits to the DB but it would be a very
> small percentage and I wouldn't worry about it.
> mostly_harmless
>

Thank you harmless, but I don't think you understand the question, as you're not a developer. Does a thread with user's goofy pics on many posts hit the DB more than a user looking at pending credits?

Rom, Paul Buck?

> Thank you harmless, but I don't think you understand the question, as you're
> not a developer. Does a thread with user's goofy pics on many posts hit the
> DB more than a user looking at pending credits?


Alright Woody, whose pic's are you calling goofy? Be careful, we might assign you a pic of J.Q.

>
> > Thank you harmless, but I don't think you understand the question, as
> you're
> > not a developer. Does a thread with user's goofy pics on many posts hit
> the
> > DB more than a user looking at pending credits?
>
>
> Alright Woody, whose pic's are you calling goofy? Be careful, we might assign
> you a pic of J.Q.

I'll bet the goofiest ones are those who really look like a couple posters! :)

(I am not nor have I ever been JQ!)

> Be careful, we might assign
> you a pic of J.Q.
>
>
I may be opening up a can of worms here but I like fishing. Who is JQ?

>
> > Be careful, we might assign
> > you a pic of J.Q.
> >
> >
> I may be opening up a can of worms here but I like fishing. Who is JQ?


Woody's bestest buddy in Boinc Beta days. ;)

Probably about the most eccentric, self centered little nerd you'd ever want to meet, but at the same time he brought a lot of life and activity to the message boards that made it more interesting. It was fun to watch the bickering.

OK I've got one - bfarrant - where'd you get the Fireball XL5 photo? Are you even old enough to have watched that show?

I am....and I did

Just spotted your comments on Fireball XL5. I can remember that show too......Returning Home.....Returning Home.....(better driver than me!!)

> Thank you harmless, but I don't think you understand the question, as you're
> not a developer. Does a thread with user's goofy pics on many posts hit the
> DB more than a user looking at pending credits?
>
> Rom, Paul Buck?

In theory it increases the total I/O by somme amount. The thing is, this is a very small piece of data, so the other were correct in saying that the increase is insignificant.

One thing to keep in mind (I was up for a couple hours just chewing this one over) is that there are two kinds of I/O in databases. Physical and Logical. In the physical you have the fetch of the record from the disk drive. This of course is subject to all the issues of disk latency (rotational and seek, look inthe glossary for explanations - also the performance faq). This you want to avoid as much as possible.

The other is logical, after the record has been fetched and is in memory you now have to extract the information out of the record. If the database is VERY smart it can fetch in only those parts of the physical record it needs.

Anyway, to move on, we have a slight increase in the physical and logical I/Os, but the increase will be small. Also, if they have hosted the web site on a different processor then there is no impact at all on the data server that we are hiting for results.

In the grand scheme of the database schema (hmm, almost a pun) this would not be one of the things that I would be looking at to optimize. Mostly because if you look at the reesponsiveness of the database when you call up a page the response time is very good (of course I have cable modem access so your mileage may vary).

We are now saddled with legacy so major changes to the schema are not likely in the near term if there is not a major performance issue. And, with many of the hardware failures behind us (I hope) we can concentrate on the other more pressing issues, then back into schema changes for the time when we have more participants in the projects.
<p>
Click Me!

> OK I've got one - bfarrant - where'd you get the Fireball XL5 photo? Are you
> even old enough to have watched that show?
>
> I am....and I did


I found it on the web, even found the theme songs to it. And yes, I watched it's first run, it was my favourite show when I was about 3 years old, and when I had seen it re-broadcast a few years ago I decided it has held up quite well.

Actually, I didn't even remember the show. But for years I would occasionally have this vague memory/image (of a glass robot that looked kind of like an old glass coffee percolator) pop up in my mind that carried some nostalgic feelings with it, but could never figure out where the memory came from. Then one night on late night TV, Fireball XL-5 tuned up, and the second I heard the opening of the show, all the memories flooded back and I remembered not only Robert the Robot and all the other characters, but some of the story lines and even sitting on our hardwood floor in front of the old black&white RCA console TV as an enthraled little toddler.

> > The amount of IO the boards generate is not significant compared to the
> other
> > functions. Yes it does generate more hits to the DB but it would be a
> very
> > small percentage and I wouldn't worry about it.
> > mostly_harmless
> >
>
> Thank you harmless, but I don't think you understand the question, as you're
> not a developer. Does a thread with user's goofy pics on many posts hit the
> DB more than a user looking at pending credits?
>
> Rom, Paul Buck?
>
The problem is not the size of the data, it is the amount of work that the query causes. The link to the avatar is almost certainly stored directly in the record for the user, and therefore has almost zero look up cost. The pages displayhing information about the individual results involves a full table scan of all of the results. This table scan to figure out which WUs belong to that user/host is the problem that was stressing the servers.

> The problem is not the size of the data, it is the amount of work that the
> query causes. The link to the avatar is almost certainly stored directly in
> the record for the user, and therefore has almost zero look up cost. The
> pages displayhing information about the individual results involves a full
> table scan of all of the results. This table scan to figure out which WUs
> belong to that user/host is the problem that was stressing the servers.
>
>>>>>>>>>>>>

I am sure as we progress, we will see more third party programs that could provide the same or similar information without even needing to have these features back on. I would prefer to just have the uldl, scheduler and validator on line and working well. Our guys at Berkeley have had plenty to keep them busy and have done a great job.
----------



Join the Overclockers.com SETI Team!

> Woody's bestest buddy in Boinc Beta days. ;)
>
> Probably about the most eccentric, self centered little nerd you'd ever want
> to meet, but at the same time he brought a lot of life and activity to the
> message boards that made it more interesting. It was fun to watch the
> bickering.
>

All I can say, is that even I thought he was a looney toon! :)

> All I can say, is that even I thought he was a looney toon! :)

I would use the term idiot... ;-)

> The problem is not the size of the data, it is the amount of work that the
> query causes. The link to the avatar is almost certainly stored directly in
> the record for the user, and therefore has almost zero look up cost. The
> pages displayhing information about the individual results involves a full
> table scan of all of the results. This table scan to figure out which WUs
> belong to that user/host is the problem that was stressing the servers.

That is what I said, sort of ... :)


<p>
Click Me!

way i see it no difernt than the I/O needed for all the sigs around here whats one avatar when lot users have multiple sigs
<p align="center"> </p>

but our sigs are'nt on the SETI servers, they are external, and the only thing in the DB for that is a line of code, a couple of bytes at best.
[/url]

> way i see it no difernt than the I/O needed for all the sigs around here
> whats one avatar when lot users have multiple sigs

and the multiple sigs are causing you to have to go out to those external servers and that is the main reason that the pages are slow right now ...
<p>
Click Me!