Welcome to the pointy end of online course registration. Cache the initial 'courses' results.
I don't know how your institution has its data organized, but I'll assume that there are X Courses available. Cache either that initial page, or cache the Matter.find() results so you aren't pinging the DB server for redundant information on every request. I've a feeling that you're stuck with your current design for now, so the solution would be to throw more capacity at the issue inexpensively by changing your web server params or clustering setup to deal with peaks (max clients, DB connections, etc - Scaling Rails reference). For the future: Of course, what would work really well for the students would be to show the available seats in any course when the course listing is returned, which means that caching won't help. But that would be a likely big design change. Another option (too late for this at the current time) is to implement a priority queue for the students. Fourth year students are allowed to register beginning at 9:00am - on the theory that they should be able to get into classes first so they can meet graduation requirements. Third year students are allowed to begin registering starting at 10:00am - they are under the next strictest set of course requirements, second year students at 11:00am, and first year students at 12:00. This forcefully distributes your load a bit, though you'll still see hourly peaks. Another option is to not show everyone everything. No student is interested in all 100 courses. The odds are that a student has in mind probably 8 courses (hopefully they are smart enough to plan ahead on the chance that they won't get into one of their favorite classes). Put a search form up front so they can enter their 5 (or however many) classes and get just those back. That return set could show the actual available seats in the course at that moment. If a seat is available, the student can try to get a seat in the course by checking Yes or Register or whatever and submitting right away. If it's already filled, the student knows they have to make another selection. What you'll probably find is that each student searches initially for just those 2 or 3 courses they really truly want, and make the rest of their course decisions based on how those requests work out. And given that some popular courses fill up fast, I'd encourage you to investigate the concept of a "wait list" for courses. Even though the course is full, a student may want to "wait list" the course just in case someone already in the class changes their mind and drops out (all the students are 'gaming' their schedules, trying to work out days and times). If a seat does become available, then the first person on the wait list should be offered the seat. Good luck! -- Posted via http://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
