I also suspect that realm can be added as a separate field when and if needed.
On Tue, Sep 14, 2010 at 4:58 PM, Geoff Van Brunt <[email protected]>wrote: > I would agree. The inclusion of a realm in the creds has not offered any > extra security, but has complicated things in the past. It may also impact > replication performance. The only way it is necessary is if there any plans > on making Sipx "mulit-domain" but that is a whole other can of worms. I > don't see that any time soon so, it might be good to remove it. > > > Geoff Van Brunt > Information Technology Manager > DST Consulting Engineers > > > From: [email protected] [mailto: > [email protected]] On Behalf Of Tony Graziano > Sent: September-13-10 9:04 PM > To: sipXecs developer discussions > Cc: [email protected] > Subject: Re: [sipx-dev] Request for comments regarding system performance > and how it's related to configuration > > As far as credentials and permissions go, then I would be curious to know > if the "domain" or "realm" part were to be removed from the credentials > (pin), would this affect this performance at all by lessening the amount of > data being projected and written? I suspect it will (but not much), but I'd > like to see that either "removed" from the system to move towards as easier > to implement sipdomain change. > > I also wonder about the "method" used to change a user field in sipxconfig. > Example: I change the caller-id on a single user and apply it, yet the > system does data and file replication on 14 different files. I think it > could be simpler, but what do I know. If only ONE field was actually being > updated is it really necessary to update the other 13? If it handled ONLY > what it needed to handle maybe this wouldn't be as big a deal? > > > On Mon, Sep 13, 2010 at 8:41 PM, Douglas Hubler <[email protected]> wrote: > > On Mon, Sep 13, 2010 at 11:03 AM, Tony Graziano < > [email protected]> wrote: > As far as backup goes, I am curious if the mongodump could be invoked from > within sipxconfig backup to include this in a normal backup, though i would > be curious how mongodump would affect performance on a system and how large > the backup would be and whether this should be included automatically or be > chosen. I am also curious how these backup setting would be altered > automatically in a HA environment assuming mongodb is a master/slave, and so > the online DB would automatically "rebuild" the offline one (i.e., a basic > restore option to say, don't use the DB i have in the backup, rebuild it > from the other node because maybe it's been offline too long and I want a > fresh copy instead of making it sync back only parts, etc.). > > My response mentioned backups at the mongodb level would be unnec for > credential and permissions. If you are saying otherwise, let me know. > > > As far as other operations, I could see that the export of parameters and > production of profiles and other operations could be less "system > impacting". > > mongodb also replicates files as well in their gridfs, but this is > considered bonus and not mentioned as part of this doc. > > > I would suspect that items like this... XX-8838 could be resolved with a > subset/rows for each sipxopenfire user could be made "ready" for query to > fix this issue, as an example. > > XX-8838 is unrelated. Issue stems from the fact postgres is not the right > tool for capturing CSEs. Could mongodb solve this too, maybe but i don't > want to distract this thread from the main objective > > > As far as registrations go, I could see if the DB were synced i would > wonder how the "heartbeat" or timers would function to make the failover to > the "secondary" proxy for a registered line occur in a shorter length of > time. I could see that with the right secret sauce, subscriptions and other > functions could be made to become a lot more failsafe, but that would > require a lot (tons) of framework changes. I would also want to understand > the actual "transaction" time with regard to subscriptions and registrations > as compared to postgres, but that might be hard to simulate until a fair > amount of framework had been done. > > I do owe folks bytes/message calculations and whether mongodb sends all > changes in bulk, or message per record. (I have to assume former, but still > have to test) . The transaction time is configurable and we'd definitely > want to put that into the control of the admin to pick loss of data on > failover v.s. network bandwidth. > > > Has thought been given to using a tunnel between systems in HA to sync > voicemail and make voicemail failover, and whether it could be an objective > achieved with the right framework and DB. There have been repeated requests > for a centralized VM system in HA, but to me thats a single point of > failure, but I could see where a pair makes sense, but if the DB was smart > enough it could "assume" the role for all users in a centralized pair if one > went down. > > re:voicemail > yes, this is yet another probably good use of mongodb and still a topic of > another day. > > re:security > I would like to consolidate all these different security mechanisms. > Tunnels seems like a nice orthogonal way to...ok, not going there, back to > the topic at hand: cred and perm dbs. > > > > I would just assume the ability to access the DB would be as "simple" as > postgres is? ODBC or whatever? I ask because one of the issues I see is > running CDR reports and CPU, and I'm not clear if that is the report > generator or the DB query spiking the CPU. > > yes, there is a console, there might be a debugging need for looking at > creds and perms on a system outside configuration database. > > > > I have seen a couple of issues with postgres DB in the past that could only > be overcome with a backup and restore, so even though I did a reindex and > other commands, it never resolved my issue. > > If it is not feasible to make the DB in postgres smarter to be less system > impacting, then perhaps this ought to be addressed by moving to something > else. I think the number one issue I'd have if everything else was equal or > better, was the backup/restore function of the DB and whether mongodb has > resolved a disk efficiency issue when the dump is made to the same disk, at > which point disk performance is impacted. > > again, at this stage no need for backups and therefore no system impact. > > > > In you test document it is not noted how big the DB was in PG or MongoDB. > Can you elaborate on that? > > FreeDB went from 2 to 5002 records. In mongodb i went from 5000 to 10000 > records. > > I know I'm all over the place with this response, but I think it's all DB > related so I wanted to comment accordingly. Even with the issues with > performance and the DB, I do find Postgres to "pretty much work", but I do > find the changes can "cripple" a system for a brief period, and that just > blows. There are major framework changes to make to add a more robust HA > system and the DB is one of those pieces. > > Postgres performance may be on par with mongodb, but the replication as a > first class operation in mongo is what we are really after. > > > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > > -- > ====================== > Tony Graziano, Manager > Telephone: 434.984.8430 > sip: [email protected] > Fax: 434.984.8431 > > Email: [email protected] > > LAN/Telephony/Security and Control Systems Helpdesk: > Telephone: 434.984.8426 > sip: [email protected] > Fax: 434.984.8427 > > Helpdesk Contract Customers: > http://www.myitdepartment.net/gethelp/ > > Why do mathematicians always confuse Halloween and Christmas? > Because 31 Oct = 25 Dec. > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: [email protected] Fax: 434.984.8431 Email: [email protected] LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: [email protected] Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ Why do mathematicians always confuse Halloween and Christmas? Because 31 Oct = 25 Dec.
_______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev/
