On Thu, 27 Apr 2006 08:42:30 -0700, Richard Gaskin wrote:
It sounds like you could safely use a separate stack file for each
user,
which might also bring a modest performance boost since it would only
be
loading the data for the current user.
I have a bug reporting tool I'll be demoing at RevCon which uses that
approach: each user has a folder on the server, and while they can
read
files from any folder they only write to the ones in their own.
In your case that may be all you need. With the bug tool I also needed
to allow admins to write to those files, so to avoid conflicts I just
write a flag file to the folder to note that it's being edited, and any
attempt at write-access to the file first checks for that flag and
reports to the user if the file they want is in use. Once the save is
done the flag file is deleted.
Thanks Richard, nice tips. I must have one stack however, because it
summarizes quiz results for all students and sends summary back to each
student.
So, I guess my option is to manage users access through flag in
external file and wait in CGI script either in repeat loop or with
send in time until access to stack is allowed.
In my case, processing time in CGI takes 5 milliseconds + 5
milliseconds on saving the stack and it's unlikely 2 users out of
50-100 would hit "finish quiz" button inside the same 10 millisecond
time spot. I hope in worth case scenario there would be just extra
20-30 milliseconds before user request would be processed. Or, if all
100 users would send request at exactly same time it would be 10x100= 1
second delay for user # 100 :). I would probably write a test stack
that would imitate and benchmark such situation.
Still, stay-resident solution for MC CGI engine would be great been it
running as daemon or with fastCGI or whatever.
Pierre in his article writes that "Only the Linux platform will
provide the opportunity to use the Metacard/Revolution applications
server in daemon mode" and while he mentions OS X and win XP as well
later and has his solution for download
"http://istream.homeunix.com/insead/index_en.html"; , it's not clear for
me if it would make MC CGI stay-resident on OS X and solve above "write
to stack" problem, even if I dig in and implement his solution.
Basically, it would be great to know if anybody succeeded in making MC
CGI stay-resident on OS X (I don't have linux box) and thus preventing
engine quitting after CGI script is executed and launching the new
copy of the engine on each call.
Any insights ?
best regards
Tariel
_______________________________________________
metacard mailing list
[email protected]
http://lists.runrev.com/mailman/listinfo/metacard
