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.
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.

> 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?

> Moreover, the testing schedule is rather tight, (we have to test about
> 15000 students in a week), so not only time to answer a single
> question, but also total test time is limited. 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? 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?

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.

>
>>>This system currently uses quota-based proprietary database which
>>>allows it to dynamically change quotas for "teacher" account depending
>>>on the system load.
>>
>>Here's what I would expect to have happen in that case. I'm a teacher,
>>I've got a big query, and I need the results. I submit my query, run
>>out of quota and lose all benefit of the work done so far.
>
> 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 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.

>
>
> >
>>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, and if
I recall correctly, the modes are associated with the client, not the
database, so an Oracle mode client can encounter data stored by a MySQL
mode client - to its considerable distress, I would guess.

Regards,


Ann