Asynchronous output buffer for calendar (c#)

Question

Ok, I'm currently writing a scheduling web app for a large company, and it needs to be fast. Normal fast (<1s) doesn't cut it with these guys, so we're aiming for <0.5s, which is hard to achieve when using postbacks.

My question is: does anyone have a suggestion of how best to buffer calendar/schedule data to speed load times?

My plan is to load the selected week's data, and another week on either side, and use these to buffer the output: i.e. it will never have load the week you've asked for, it'll always have that in memory, and it'll buffer the weeks on either side for when you next change.

However, I'm not sure exactly how to achieve this, the asynch loading is simple when using ajax pagemethods, but it's a question of where to store the data (temporarily) after it loads: I am currently using a static class with a dictionary> to do it, but this is probably not the best way when it comes to scaling to the large userbase.

Any suggestions?

EDIT

The amount of data loaded is not particularly high (there are a few fields on each appointment, which are converted to a small container class and have some processing done on them to organise the dates and calculate the concurrent appointments, and it's unlikely there'll be more than ~30 appointments a week due to the domain) however the database is under very high load from other areas of the application (this is a very large scale system with thousands of users transfering a large volume of information around).

Answer 1

The buffering won't help on the first page, though - only on subsequent back/forward requests.

Tbh I don't think there's much point, as you'll want to support hyperlinks and redirects from other sources as much as or more than just back/forward. You might also want to "jump" to a month. Forcing users to page back and forwards to get to the month they want is actually going to take longer and be more frustrating than a <1s response time to go straight to the page they want.

You're better off caching data generally (using something like Velocity) so that you almost never hit the db, but even that's going to be hard with lots of users.

My recommendation is to get it working, then use a profiling tool (like ANTS Profiler) to see which bits of code you can optimise once it's functionally correct.

Answer 2

So are you putting your buffered content on the client or the server here? I would think the thing to do would be to chuck the data for previous and next weeks into a javascript data structure on the page and then let the client arrange it for you. Then you could just be bouncing back to the server asynchronously for the next week when one of your buffered neighbour weeks is opened so you're always a week ahead as you have said, assuming that the data will only be accessed in a week-by-week way.

I would also, for the sake of experimentation, see what happens if you put a lot more calendar data into the page to process with Javascript - this type of data can often be pretty small, even a lot of information barely adding up to the equivalent of a small image in terms of data transfer - and you may well find that you can have quiet a bit of information cached ahead of time.

It can be really easy to assume that because you have a tool like Ajax you should be using it the whole time, but then I do use a hammer for pretty much all jobs around the home, so I'm a fine one to talk on that front.