• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 142
  • Last Modified:

multi threading scenario blazing fast read/ secondary update of read data

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

1 Solution
While it may be a multithreaded app, your best approach is to break it down into the two logical parts, the reading of the data, and the updating of the metric stuff.

The reading of the data can be handled like you said, or a few other ways that should still be very fast.

The updating should just be stuck in a webservice as a function that is called ansyncronously, that way the webserver that handles the updates will take any of the load for the updates and the user will continue whaterver they are doing with no response time.

Featured Post


Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now