Web Virtual Waiting Room

We started using a proper waiting room this year and so far, during busy on-sales, it's worked a treat! Depending on your hardware arrangements, you can get a very sizeable waiting room that will effectively throttle the number of people hitting your main server.

As preparation, it's probably worth running a few queries to show you the number of orders made online on busiest days.

A very quick and simple example of that would be something along these lines:

select order_no,solicitor,order_dt
from t_order(NOLOCK)
where created_by = 'webapi' --replace with your web API user-name(s)
and order_dt between '2009-05-29' and '2009-05-30' --replace with your date/time range
order by order_dt

Pick the busiest day you can remember and arrange the results in a spreadsheet to show you the peak hourly usage. That could indicate the best way for your IT guys in terms of the scale of the hardware required, etc. This will not show you the users actually hitting the site, but rather purchasing through it. However, the other statistics should be readily available through your hosting company or the IT department.

This is, of course, only one step, but one has to start somewhere, right? :)

Michael,

How did you go about implementing the waiting room? Is it on the database side or on the web side of things? Any information you can provide would be much appreciated since we are looking at implementing a waiting room.

Thanks!

Naomi

We had our website and the waiting room designed by POP at the same time, so I'm afraid I haven't got anything on the actual implementation, sorry...

However, as far as I know it has little to do with the database and much more to do with a separate web server handling incoming connecitons that reach a pre-set threshold.

We had this same problem and we spent a considerable amount of time and money to resolve it. It turned out to be many problems and not just one. Some of the issues we encountered:

- Bandwidth size and speed for both the API and web servers (assuming they are in different locations)

- Server RAM available (we increased the RAM on our database server to 8GB) We bought Windows Server Enterprise edition so the system would recognize and use the extra RAM.

- Best Seating - we set up smaller sections for large venues. This helps the best seating function because the system did not have to scroll through large sections to find the next available seat. We have a 10,000 seat venue and we split it up int sections of 100 or more. We also improved the performance of best seating by allowing it to leave single seats.

- SOAP compression - this is part of the web application

There were other smaller issues but you may get the point. I suggest having an experience technical resource take a look at the whole picture to help you discover where your weak points are. We did this and our consultant set up a testing routine that would place orders so that we could see where the system was slowing down. You can narrow it down to a process (credit cards, seating, etc.) and you can also narrow it down by web page. This helped us tremendously as it led us to the Best Seating issue.

All this being said, it is difficult to size a system to handle these large sales that happen just a few times a year. So no, I don't think that a virtual waiting room is THE answer. I suspect you have a variety of issues going on. This is an ongoing issue and to resolve some of these issues it took about 6 months of testing and working with several people (Tessitura, web developer, ISP, technical consultant, etc.).

Hope this helps.