I have a web application (asp.net) where work items are submitted and allocated to users according to their workload.
A user’s workload is calculated using an algorithm based on the number of items currently allocated to the user (and some other factors). Each new item is allocated to the user with the lowest current workload, increasing their workload. A user’s workload decreases when they finish an item. Items will be submitted, allocated and finished concurrently – hence workload levels will be continually changing. Work items are stored in a SQL database.
I need a way to ensure that every allocation decision is made using an up-to-date picture of workload across the user base.
My idea is to provide a read/write synchronized store of workload information in the Cache.
Is this the best approach? Or should I use the database to control locking? How do I avoid bottle-necks in my application?
Advice much appreciated.
This depends on many factors, when you refer to the cache do you mean the standard cache provided by Asp.Net?
Is it absolutely critical that you always have the most up to date information, or if two requests are made to be allocated is it ok for them to get allocated to the two least busy users at the moment the request was made?
You can indeed use a cache to store this information, however this generally assumes you will only be using one server, is it likely that you will be using clustering or load balancing for high loads?
The best advice I can give you is to build a well designed application, with a rich domain model representing the loads of each user and the queue and loosely coupled data access and plenty of automated unit and system tests. This way you can build a working application, get the system up and running quickly without worrying to much about optimisation and start performance testing\profiling as soon as possible.
If\when you encounter performance issues, you can then identity the bottlenecks by profiling\tracing and add optimisation as appropriate, which might be caching or optimised queries\views or combinations of things.
If you try to second guess where you’re bottlenecks are and remove them, you will likely guess wrong and damage the design of the system. A well designed system can be optimised when you need it.
The way I would initially envisage this, would be a relational database (possibly using views or stored procedures to grab workload summary information quickly) with a data mapping layer between this and the domain model (which can use caching, lazy loading and identity mapping to provide efficiencies if needed). The domain model would largely hold a representation of the workload.
I would expect this to have users, work items, work queue and allocation strategy classes. Much of this could be kept in memory or stored locally between requests, each request could be represented by an event which would update the model.
E.g.
User completes a work item
Site raises a domain event to notify the domain model of change
Domain model receives event and updates work load for user
Work allocation would then be a matter of asking the domain model to allocate the work (which it would do via a strategy of finding the least allocated user) when needed. This could happen in the background outside of individual work requests and events raised to notify users next time they ask for work.