Re: [Asterisk-Users] realtime excessive database queries
> Personally I would rather see realtime load everything into memory and > not go to the database unless something has changed or you reload. > Then maybe add a new manager command like the following: Then don't use realtime extensions, use the static database functions in realtime to load your dialplan. It's already there. /O ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
snacktime wrote: Personally I would rather see realtime load everything into memory and not go to the database unless something has changed or you reload. How would this be different than just storing the configuration statically in the database, and reading it at startup and at subsequent reloads? The primary deal with realtime, as I understand it, is that it *doesn't* keep the extensions tree (or whichever) in memory. Even the caching that's implemented for ARA right now takes it a bit away from that. Not trying to jab at you here, but try to understand the exact differentiation of function. Thx. B. ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
> Rather than caching the data, which would remember the data past it's > useby date (which is never a fixed value, the useby date is when the > data in the DB is modified, which could be at anytime!), we should > simply read the entire extension in a single select, and cache that > answer for the life of the channel, or until it moves to another > extension. > > This will help assure that the extension is always in some consistent > state ie, it is either the old set of values, OR the new set, but > not going to start with the old set, get to priority 5, and suddenly > break because we changed things... I agree that's a good idea. However with a good cache mechanism you don't have to worry about getting old data. When you update the database you delete that item from the cache, which forces the client to get the new value from the database the next time it needs it. Or you tell the client somehow to reload the changed item. Personally I would rather see realtime load everything into memory and not go to the database unless something has changed or you reload. Then maybe add a new manager command like the following: RealtimeReload(context|all,extension|all) Which would trigger asterisk to reload from the database, locking access to the context/extension until the reload was complete. Another nice thing about this approach is that if your database (god forbid) goes down, asterisk can keep humming along. Chris ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
> we should > simply read the entire extension in a single select, and cache that > answer for the life of the channel, or until it moves to another > extension. That sounds like a good idea. -Matthew ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
On Sun, 2005-05-22 at 18:44 -0700, snacktime wrote: > On 5/22/05, Preston Garrison <[EMAIL PROTECTED]> wrote: > The biggest problem is several routines > > would need to be modified to pass around the data. It was just easier > > to put hooks in all the functions for the database. Writing your own > > database interface and caching the queries could do it as well. > > I was thinking about using postgresql with odbc since postgresql has > an interface to memcached which we use a lot anyways. And with > postgresql I could just use a few rules to rewrite the queries from > asterisk and not have to touch the asterisk odbc code. This also > makes sense for us because we are already using postgresql with > memcached for a bunch of other stuff. Rather than caching the data, which would remember the data past it's useby date (which is never a fixed value, the useby date is when the data in the DB is modified, which could be at anytime!), we should simply read the entire extension in a single select, and cache that answer for the life of the channel, or until it moves to another extension. This will help assure that the extension is always in some consistent state ie, it is either the old set of values, OR the new set, but not going to start with the old set, get to priority 5, and suddenly break because we changed things... Just my 0.02c worth, or less, since I haven't even read the code ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
On 5/22/05, Preston Garrison <[EMAIL PROTECTED]> wrote: > Why not add the code to do so? I'm not the best C programmer or I would. I can see what needs to be done and could put all the logic together, but the actual coding would take me a while. The biggest problem is several routines > would need to be modified to pass around the data. It was just easier > to put hooks in all the functions for the database. Writing your own > database interface and caching the queries could do it as well. I was thinking about using postgresql with odbc since postgresql has an interface to memcached which we use a lot anyways. And with postgresql I could just use a few rules to rewrite the queries from asterisk and not have to touch the asterisk odbc code. This also makes sense for us because we are already using postgresql with memcached for a bunch of other stuff. Chris ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
Why not add the code to do so? The biggest problem is several routines would need to be modified to pass around the data. It was just easier to put hooks in all the functions for the database. Writing your own database interface and caching the queries could do it as well. We eventually dumped the idea of using an external database period, and ended up putting our own hash based system in place. Preston Garrison direct: 877-748-4142 fax: 310-774-3901 cell: 623-748-4140 -Original Message- From: Matthew Boehm <[EMAIL PROTECTED]> To: snacktime <[EMAIL PROTECTED]>; Asterisk Users Sent: Sun, 22 May 2005 12:27:06 -0500 Subject: Re: [Asterisk-Users] realtime excessive database queries The queries you speak of are not native to realtime. They are part of pbx as a whole. And yes, the core programmers are aware of it and yes, they have admitted they don't like it. > Why not just load all the extensions into memory, and then have a > mechanism to mark an extension as stale and only then reload from the > database? Seems that with a basic caching mechanism you get all the > benefits of realtime without the downside of taking a performance hit > like it does now when having to go to the database so much. > > If I'm reading the code right the extensions are all in a linked list. > So it seems you could just add another item to the list to hold the > state of the extension, and when accessing the first item in the list > check the state. If it's stale and realtime is in use, update the > extension from the database and restart at the top of the list. > > Chris _Matthew ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [Asterisk-Users] realtime excessive database queries
The queries you speak of are not native to realtime. They are part of pbx as a whole. And yes, the core programmers are aware of it and yes, they have admitted they don't like it. > Why not just load all the extensions into memory, and then have a > mechanism to mark an extension as stale and only then reload from the > database? Seems that with a basic caching mechanism you get all the > benefits of realtime without the downside of taking a performance hit > like it does now when having to go to the database so much. > > If I'm reading the code right the extensions are all in a linked list. > So it seems you could just add another item to the list to hold the > state of the extension, and when accessing the first item in the list > check the state. If it's stale and realtime is in use, update the > extension from the database and restart at the top of the list. > > Chris _Matthew ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[Asterisk-Users] realtime excessive database queries
Does asterisk really need to be doing 3 database calls for every priority in every extension? Why not just load all the extensions into memory, and then have a mechanism to mark an extension as stale and only then reload from the database? Seems that with a basic caching mechanism you get all the benefits of realtime without the downside of taking a performance hit like it does now when having to go to the database so much. If I'm reading the code right the extensions are all in a linked list. So it seems you could just add another item to the list to hold the state of the extension, and when accessing the first item in the list check the state. If it's stale and realtime is in use, update the extension from the database and restart at the top of the list. Chris ___ Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
