multi threading scenario blazing fast read/ secondary update of read data
Posted on 2007-10-17
i have an app that is currently running only in a local server intranet environment. it breaks all the rules concerning multi teir programming. but it is blazing fast. reads and writes and updates in no time at all.
while it will work in a WAN environment, the response time takes a noticable hit. It slows to the point where it will not be able to be used at that level of response.
there are very likely things i could do with the app to speed it up, tweak indexes, verify all cursors are proper, etc.... however, it is likely that i just need to "do it the right way".
at some point in the nearish future we are going to need to move to a WAN environment and i am going to need the same response to input as i am getting now.
i am an extreeme noob when it comes to .net and web services and where the edges of the layers (UI, Busines logic) are.
the part of the app that MUST be fast is the read part, the operator inputs a number and a look up occurs that then indicates to the operator some information concerning the number. This operation, as far as the operator is concerned, must be virtually instantanous. the second part of what happens with each input is not as critical as far as a speed/response time and that is updating the record with several pcs of metric info and some checks and possible updating and/or creating records in other tables.
from the brief info i have been able to gather, i think that at least as a start we would have something like this as the setup.
(i may not get all the naming conventions correct but i think that the concept will be able to be conveyed)
web server with .net services
work station remote running a small UI app
at the beginning of a sesion, the workstation would download and maintain a local, readonly, dynamicaly searchable record set of potential items that could be entered (this set is static and know ahead of time and is a significantly smaller subset of the universe of possibly entered valid items). the lookup of info in this case should be very very fast. the second set of operations would then start, that would do all the updating/adding/writing.
my understanding is that while this is being done, we could (before it is finished doing all the second part stuff) go back and do another input and look up in the first part.
my question is this, is this a multi thread candidate?
or something else?
basically, what i need is one "thread" that all it does is look up entry and display what it finds. i then need a second one that takes that info and does the neccessary updating/logging/checking on all the items entered in the first one, but with out holding up the first one as far as time goes.
i hope i am being clear enough