Post reply

Calculating I/O

  • August 7, 2003 at 4:08 pm

    #358102

    We are designing a database for an application that will collect data on voice response systems. It will connect to SQL Server via ODBC and we are trying to figure out what we will need in terms of hardware.

    It is conservatively estimated that we will be handling 35 million calls a year. The way we are breaking the data down will translate to multiple inserts per call.(through SPs that pass back a GUID)

    Any clue how I would begin to calculate I/O or for that matter any relevant choke point? Database size is simple enough but I know that there will be peak times when we have many simultaneous calls and I am concerned that we will run into issues with congestion.

    Anybody have any experience with this?

    Thanks!


    "I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
    (Memoirs of a geek)

  • August 7, 2003 at 5:24 pm

    #469106

    How many calls per sec during expected peak traffic

    Potential hotspots on some tables with inserts.

  • August 8, 2003 at 4:25 am

    #469157

    I don't know your business, but if we limit the calls to 8 hours per day / 5 days a week, thats 175,000 calls an hour. It depends on what data you are trying to collect. Will it be information from the calls, or will it be that actual digitized voice from the call.

    The former doesn't seem to pose much of a problem for a "properly" designed system, but the latter would pose a big problem as each call would represent many physical disk writes.

    Which condition do you have.

  • August 8, 2003 at 6:58 am

    #469169

    Well, the more IO the marrier. Remember the peak a box can handle or at least an Intel 8 way box is around 400 to 500 meg a second in adjusted througput. This was achived by hooking the box upto two EMC 8700 SAN's configured raid 0+1 and 8 HBA's in the system. Your milage may vary. If you are attaching to a SAN the more HBA's the better if it is external scsi storage a single drive shelf per controller usually a maximim of 4 controllers is all you can squeze in these machines these days is going to net you some decent IO. Also keep in mind that RAID levels will also effect performance. It takes twice as many write operations in a RAID5 setup as it does in a raid 1 or raid 0+1 configureation. Money is usually the dicator of these kinds of things though. And that is just hardware considerations. You can also increase performance with good file placement as well.

    Good luck with your project.

    Wes

  • August 8, 2003 at 7:28 am

    #469172

    I would consider queueing or using multiple servers to help handle that size load.

  • August 8, 2003 at 7:47 am

    #469177

    Ok,

    Peak traffic? - I don't have that info yet.

    My business? - I'm new so I don't want to say specifically but let's just say that this is the database for an IVR system (One of those voice mail tree things that you call in and press 1 for this and 2 for that etc.) The system is being used for people to manage their club memberships. 8 to 5 / 5 days a week? Not likely!

    What I'm really looking for here is how to calculate the cost of a single call to a stored procedure in terms of I/O. I'm not sure of the right terminology or even what's the nature of this cost. Bandwidth? Throughput? I/O? (It's so difficult to research something when you don't know the proper terminology!)

    Also, where exactly do I need to be looking for choke points. Network? Disk? Do I need: Multiple NICs? Multiple Raids? (SAN Sheesh! I wish!)

    Feel free to treat me as if I know nothing!

    Thanks.


    "I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
    (Memoirs of a geek)

  • August 8, 2003 at 7:51 am

    #469179

    leet:

    When you say queueing, are you thinking MSMQ to temporarily store things so during really busy periods the queue fills up somewhat, then when things slow down abit the queue empties?

  • August 8, 2003 at 7:58 am

    #469180

    I have specific experience on this kind of a setup. I have an SQL database and an 8 port IVR setup. Our volume is lower than what you are saying, but otherwise similar setup.

    We receive about 25,000 - 35,000 calls per month. Our system is 24/7, and real time.

    It is used for account inquiries and for authorizing transactions through our "club".

    Stored Procedures handle all the checks, updates and validations.

    Dialogic hardware handles the calls.

    THe software is written in Visual Basic, with vbVoice 4 as the component that handles the TAPI/IVR portion.

    With a little more information, perhaps I can provide some feedback that you might find valuable.

  • August 8, 2003 at 8:53 am

    #469196

    Philster,

    Yes, something along that idea. I've seen it work very well, but it is not always ideal and depends on the situation. I would imagine that account management transactions over the phone would need to be done quickly, especially if for a bank or something. Then again, if you're placing orders, it wouldn't matter so much if it went in immediately or 5 minutes later as long as it was recorded.

  • August 8, 2003 at 11:09 am

    #469224

    Thanks for the input folks!

    Feel free to continue adding your two cents.


    "I met Larry Niven at ConClave 27...AND I fixed his computer. How cool is that?"
    (Memoirs of a geek)

Viewing 10 posts - 1 through 9 (of 9 total)

You must be logged in to reply to this topic. Login to reply