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/
