Big Size Database and increasing number of users
You're asking a scaling issue which can be solved in many different ways using different technologies based on your current restraints and environments.  If the issue is coming from locking you can change the isolation level to snapshot isolation if you don't mind seeing the old value until the new ones is complete.  This is good if you have plenty of TempDB space and can afford an extra 14 or so bytes per row for the version overhead.

You can use snapshots to query the old data but as new data is added expect slower performance if your snapshot disks aren't fast enough to query the stale data.  

You can mirror the data to a different server, read that from a snapshot and update the snapshot after all write operations are complete and replicated.  This will cause your queries to fail while you make a new snapshot but that's very fast, or you could just snapshot by day and delete the old one.  The problem with this is that standard edition of SQL Server requires you write to the mirrored pair first, then to the primary.  This means if the secondary is down the writes on the primary won't commit.  This isn't bad in your scenario actually since they only get updated once per day and if the network is fast enough, along with fast enough disks on the 2nd side to snapshot report from and write to, you're good to go.

Do you have 2 servers?  If so, I'd say mirror to the secondary in this scenario and always perform your reads against a snapshot which get's recreated once a day after the primary is updated and mirrored over.

Edit:
Note there is a HUGE difference between "Database Snapshots" and "Snapshot Isolation".  Snapshot Isolation works on a ROW level and is done to let you read the old value while the new one is being updated.  "Database Snapshots" work by making a copy of the old data page when it changes and referencing that, and it will stay until you drop it.  Note neither of these will help you if the issue is memory or disk IO.