Sorry, one other question... what are the results like for "changes" to 5,000 users instead of adding them?
I am not a DB expert, but insert records into a db does not typically impact a system as much as "changing" 5,000 records that have already been written. How hard would it be to simulate a test like that? I would also suspect the time to reach the other DB if it were on a different server and/or network might make the transaction take longer, and use a higher amount of cpu (or not) longer than duplicating the records into a DB on the same disk using the same box. I simply suspect it might be a more prolonged duration than the test, but less than the current one. I'm not knocking the test, and I understand the logistic difficulties in doing the tests that were done. I think that I surmise the CPU utilization would still be lower, and for a less prolonged period of time simply because it would be more efficient. While there may be huge savings in CPU cycles, I don;t think I would characterize the ration of the test as accurate becuase there is no real good way to test that at the moment. (I do think efficiencies could be gained. I'm not knocking anything.) On Mon, Sep 13, 2010 at 11:03 AM, Tony Graziano < [email protected]> wrote: > 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. > > -- ====================== 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/
