On 6/22/05, Ann W. Harrison <aharrison@...> wrote:

> Alexander Klenin wrote:
>
> > Well, I admit that I sometimes write stupid programs, but not THAT stupid ;-)
> > Sure, we try to count "think time", but that is not as easy as it sounds.
> > For example, the submit time is taken from database server for
> > security and consistency,
> > but the server could have a problem even answering a query like
> > SELECT CURRENT_TIMESTAMP FROM RDB$DATABASE.
>
> I wouldn't use a separate query to get the time. You could set a
> timestamp field to 'now' with a trigger on the last record inserted or
> updated when a question is sent to a student and another similar trigger
> on the on the first record inserted or updated when the answer returns.

This is how it is done, and it is exactly the root of the problem.
When the database is overloaded -- by the time the trigger execution
starts, it is already too late -- by 5 to 15 seconds, as measured.

> Better, assuming your application has some way to notice that it has
> sent a question to a student, and maintains some context about who that
> student is. Get the system time when the question is sent. Get the
> system time when the answer is received.

The problem here is that HTTP protocol is stateless by definition --
and I think that even Jim, for all his affection with self-made
solutions, would agree that reinventing HTTP is not very wise deсision
;-) When the load-balancing is on, there is even no guarantee that
question and answer will be processed by the same server.

> > Another problem is that not all clients are web-servers, there are
> > some Windows-clients connecting directly do database, so counting time
> > on web-server is not always even an option.
> Why not? Are the other clients also testing?

This is complex issue, I can delve into it in depth, but but for a
sake of current discussion let's just assume the mix of two-tier and
three-tier access -- surely not an unheard-of scenario.

> > So the situation where
> > every student is forced to wait extra 30 seconds after each question
> > is totally unacceptable.
> And how would quotas help that?

See below.

> I'm taking a test, I've spent an
> average of .6 seconds on each query but the transmission time brings me
> over the arbitrary quota for the test. So I flunk?

Neither average time per query not transmission time have nothing to
do with the problem. As for transmission time -- we simply advise
students not to take official tests over dial-up connections ;-)

> What would you limit and which users would you put limits on? Tell me
> more specifically how you would use quotas to solve these problems, please.

The limit is be put on the total (wall-clock) time spent sinse the
query was issued.
There are actually another limits, like queries issued per hour, but
that is another story.

> > How do you loose anything? The time to select query parameters is
> > perhaps 10-15 seconds -- you will just see a message telling that the
> > system is overloaded and asking you to resubmit your query in a few
> > minutes.
>
> The system has spent 10-15 seconds processing a query ...

No, please read carefully (or perhaps my english is incomprhensible?
-- if so, please tell me, I am not too good at english). I wrote "The
time to select query parameters" -- that is, the time spent by user in
the interface.

> ... that it could not complete and dropped on the floor.

> Those 10-15 seconds could more
> profitable used for anything that was actually allowed to finish,
> instead they're completely wasted.

Oh, if you implement a feature to accurately predict time required to
complete the query, that would be ideal! But somehow I do think this
is much harder then implenent quotas.

> >>If that works for you, fine. Be careful of funny dates - I'll bet your
> >>application will have a grand time with 2005.0.15 and such MySQL
> >>specialties.
> >
> > These are fixed too -- this is why we are considering 5.0, but not 4.x.
> Actually, I think they're fixed in some modes and not in others, ...

Yes, there are still problems -- but it is at least usable now ;-)

--
Alexander S. Klenin
Insight Experts Ltd.