I am thinking whatever software components are used it make very good sense to implement and use only packages that are actively maintained.
I agree with Douglas that this approach could really help alleviate these issues. I've seen them, and wonder how these might be implemented to make other services more reliable or perform better. I appreciate the fact that someone has taken what looks like to be considerable time to investigate this information, and provide sample performance data. 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.). 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". 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. Pointedly I would wonder if the IMBOT function could use a query function to grab the results and send them back to resolve http://track.sipfoundry.org/browse/XX-8838 perhaps by running a cron or scheduled job to create a ready to answer for call history using MongoDB... 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. 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. 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. 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. In you test document it is not noted how big the DB was in PG or MongoDB. Can you elaborate on that? 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. You asked for it, you got it. Comments... On Mon, Sep 13, 2010 at 7:49 AM, Paul Scheepens <[email protected]> wrote: > I think some people reacted off-list, but I think this would be very much > welcomed by everybody. > > My first concern would be whether MongoDB is "failsave" with regard to > power-loss etc. > I don't know MongoDB but maybe it would be possible to have some automated > distributed backups of the database as well. > Like a daily (7), weekly(4) and monthly(3) backup. > > BTW: Search "as as" replace with "as". > > Paul > > > From: Douglas Hubler <[email protected]> To: sipX developers < > [email protected]> Date: 10-09-2010 15:49 Subject: [sipx-dev] > Request for comments regarding system performance and how it's related to > configuration Sent by: [email protected] > ------------------------------ > > > > I put this doc together for a customer that is troubled by > configuration changes impacting the overall system performance. Even > though this doc talk about large systems, even small systems with > limited resources are affected. > > > https://docs.google.com/document/pub?id=1tiJNnpkbphdYJueQXV-LXqSRpB5O-yseHGPmcI-PZSg > > Please send me your comments if you have any. > _______________________________________________ > sipx-dev mailing list > [email protected] > List Archive: http://list.sipfoundry.org/archive/sipx-dev/ > > > _______________________________________________ > 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/
