Wow, all sorts of ideas, suggestions, brickbats and the like.
Makes me feel right at home, I used to moderate a flight simulation forum for a number of years, and thread police were every bit as active there too :<)
OK, clarify, and yes, the point about not knowing the Perl jargon is well made, that's the major hassle, getting to know the terminology of the language.
I perhaps understated a few things, in that while Perl, HTML and related language use is new to me, on line real time transaction processing and programming is not, I've been doing that for over 20 years, albeit on different hardware and software.
On the mini, we completed a screen, sent it to the processor, and it ran a thread, (stateless) which at the end probably sent some form of response back to the user, sometimes with data embedded, sometimes as a data collection screen, sometimes both. So far, identical to what is happening on the server, albeit different languages and communications protocol.
One of the things we could also do was to start an asynchronous thread/task that did not return to the user but did whatever it was supposed to, and then exited.
In this case, it was a short task, designed to reduce the response time to the user, by dealing with the less urgent stuff at a lower priority, or in a lower priority thread process routine
Yes, we could also run large "batch" type jobs using a similar system, but the constraint there was things like record and file locking implications, so the "batch" jobs usually had to all share one thread and were queued, to avoid deadly embrace conflicts, and in some cases, they were set to run on a very delayed basis, like after the on line day was completed.
That's the other difference, there's no such concept in web work, as it's 24/7 unless the server is taken off line for some reason
So, I'd like to be able to do something like the first thread concept, so my logic flow is:-
collect screen input,
validate,
create some DB records or whatever,
set up the mail "screen" record, and start that process, (it might well queue depending on the host machine)
complete the main line task,
refresh the user screen with the result of the transaction and finish this thread.
If it's uniprocessing threads, as soon as that finished, the mail process loads, executes and exits, happy unless something nasty has happened.
The beauty of that is that the identical process/program/screen can be used stand alone to generate a copy of the original, without any extra code, and testing it a lot simpler, as it's stand alone, with no other integration to worry about, and implementing it in the larger thread is simply a case of define the buffer, load the variables in to it, associate it with the thread and then submit it by whatever means the system supports.
The other advantage is that I've sent the user the response and then I deal with the internal housekeeping stuff that needs to be done, without making the user wait for the response, which keeps the user happy, as the response time is shorter.
As far as I can see, that's not Fork, in that I don't want to run another copy of the same thread, and (terminology again) I don't know what else it might be described as in order to search CPAN, which believe me, I have been doing, with considerable success and a few dissapointments along the way. On the mini, it was a background thread, but in every other respect, it's just another script being activated, but instead of coming from a browser, it's coming from the application itself
Yes, I could run it as a subroutine from a library file, and just include it at runtime, but I still then have to have a front end screen to test it, and do the other things, wheras if I can create it as a complete script, it make for less work, maintenance and documentation, all of which I will appreciate as this thing grows over time, and believe me, it will. I also lose the response time advantage by running it as a sub
And to the cynic who suggested forget the original and start again, not an option, it's been live for 3 days, and we've taken 15 orders from a cold start, and while I know there are several things that I will be very definitely changing as time goes on, and I get to understand Perl better, the underlying HTML and end user "feel" will not be changing much, as the response we've had so far is very positive.
Relational database, Global positioning, user history, previous order recall, real time link to delivery drivers, it's all been thought through, and will happen, now that it's earning money.
Thanks guys and gals, hope this makes what I want to do a bit clearer
Cheers
Steve
| [reply] |
More brickbats I'm afraid. :-)
I would add to hangon's suggestion, you really want to avoid considering forking and threading until you are really sure you need it. You won't know you need it until you set up your app and it runs to slow. Even then there are other methods that would likely be more effective at speeding things up (e.g. mod_perl, better hoster, hardware). We're keen to see evidence of using a 'library' (module) slowing down a cgi app (give us the numbers :-).
Using a relational db (e.g. MySQL) will take care of a lot of your worries - that's what it's for.
Generally, there isn't anything in a typical shopping site that would be considered "a long running process". And, again, you won't know for sure until you've tried it.
Something like CGI::Application with CGI::Simple, CGI::Session, HTML::Template, DBI could well give you the reponse times you want. You will also have something that you and others will find more straightforward to maintain. There are many successful shopping sites that do just this.
CGI::App comes with many plugins that will do most of the tasks you need virtually out of the box, it comes with good docs, tutorials, examples (including shopping) and has its own web site (there are others, but I think CGI::App is a good introduction).
I can't help feeling you're introducing massive complexity when you don't need to. Set the thing up. See how it goes. Identify any bottlenecks and the monks will be pleased to wade in and help. While you're getting 15 orders every 3 days is a good time to try it. :-)
Good luck!
| [reply] |