That's an awful lot of assumptions, my friend. What we care about is how long it takes to get the FIRST result, not all of them together. I mean, I only need to call ONE number, not 1000...
This comes to a statement of optimal. What is optimal? Optimal with respect to what??? We want something that adds as close to 0 to the time to connect a call. If your database is not in memory at the time (swapped out, whatever) then there is overhead that you have to consider. No, it's not technically part of the database's time, but that is inconsequential. That's time a user will have to wait. And then what happens when reads are non-sequential? Is the database going to be local, or over a network? How long does a timeout take if the DB goes down? How are you going to deal with rebuilding indexes or getting backed up (i.e. lookups are a bit slower when the DBMS is working on other stuff)? I guess the point is this: if you're not careful in your implementation, this feature could be very dangerous. It's a fundamental issue with using a database with a real-time system. Web traffic hitting a database is great because it doesn't matter if a response takes 2 ms or 200 ms. And people are used to having to click "refresh" if it doesn't pop up in about 30 seconds. People expect more from voice. Having said that, I would like to see a database schema to define the dialplan, voicemail, features, etc. Then, it would be nice for * to read the info it needs and put it in a more efficient data structure, perhaps on a timed basis (i.e. every hour or so). This would give us the niceness of a PHP interface for configuration while giving us the quick response we currently enjoy when making phone calls. It would also allow the creation of one "master" dial plan that could then be spread across servers (more) easily, moved around, a server replaced, etc. And we could give Suzzy Secretary the rights to add new extensions or reset voicemail passwords for one subset of extensions, but not delete extensions. As a first step, I am working to engineer a way to intelligently define a database and create a script to write all of the little .conf files. I have no code yet; it's still cooking in the old brain. It has to be well thought out for it to be really useful. I'm writing a design document to formalize what each piece is going to do. Thoughts? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:asterisk-users- > [EMAIL PROTECTED] On Behalf Of WipeOut > Sent: Wednesday, November 12, 2003 12:25 PM > To: [EMAIL PROTECTED] > Subject: Re: [Asterisk-Users] OT : For the SQL gurus.. > > David Gomillion wrote: > > >>>>Test script of 1000 quieries.. > >>>>Query1 ("code" field not indexed) = 47.183s > >>>>Query1 ("code" field indexed) = 45.731s > >>>>Query2 ("code" field not indexed) = 109.321s > >>>>Query2 ("code" field indexed) = 2.302s > >>>> > >>>> > >>>> > >>>> > >I disagree with your disagreement :P We have to keep in mind the big > >picture. We are providing dial tone. I don't want to have to wait an > >extra 2.302 seconds for my call to be set up. Also, think of the big > >organizations: if you have 200 phone calls, and you have each one take > >even a couple of seconds extra, you are going to have to add more > >lines... > > > > > > > David, > > Please read again.. it was 2.3s for 1000 queries being run in a loop one > after the other.. that means about 0.0023s for 1.. so you would get your > dialtone pretty quick!!.. :) > > _______________________________________________ > Asterisk-Users mailing list > [EMAIL PROTECTED] > http://lists.digium.com/mailman/listinfo/asterisk-users _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users
