<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: [Freeswitch-users] Performance bottleneck</TITLE>
<META http-equiv=Content-Type content="text/html; charset=us-ascii">
<META content="MSHTML 6.00.6000.16674" name=GENERATOR></HEAD>
<BODY>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>I dont know if this makes any sense - it's just an
idea.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>If you're willing to take the hit of running MySQL, I know
that it's replication features could potentially be used. You can have the
primary MySQL server run in ramdisk and get all the performance benefits of
doing so while also writing log files to the ram disk in a seperate area. Those
logfiles can, using MySQL's built in replication features, be copied over to a
backup server and played backup, giving you both a hot spare as well as a disk
based backup.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>This does three things for you:</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>1) Gives you backup on disk, while preserving performance
in RAM</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>2) Gives you a live backup that you can quickly shunt
things over to if for some reason the primary dies</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>3) Allows you to handle spikes in volume. MySQL by default
will just write to the log files and they can be played back later by the
(slower) backup server, so a spike in volume of calls should not cause the
server to slow down per say. There is a small risk your data will be lost if
there is a failure for whatever is not copied over to the (slower) backup
server, but that's unlikely to be that huge a lag (better then
nothing).</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV dir=ltr align=left><SPAN class=072483019-12082008><FONT face=Arial
color=#0000ff size=2>As to whether any of this applies (like why the heck you'd
install MySQL on a ramdisk to start), I can't say. but it's a thought...Oh, and
you need a lot of RAM ;-)</FONT></SPAN></DIV><BR>
<DIV class=OutlookMessageHeader lang=en-us dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Ken Rice [mailto:krice@suspicious.org]
<BR><B>Sent:</B> Tuesday, August 12, 2008 11:44 AM<BR><B>To:</B>
freeswitch-users@lists.freeswitch.org<BR><B>Subject:</B> Re: [Freeswitch-users]
Performance bottleneck<BR></FONT><BR></DIV>
<DIV></DIV><FONT size=4><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt">Actually I don’t know of any mechanism that will back up
the DB... Where sqlite does work well for small to medium installations it only
scales to a point... Sqlite does not reuse ‘nodes’ in the db on an update... It
marks them as dead and creates a new entry... While this works ok on smaller
tables w/ light to medium updates after a while you have to compress or vacuum
the tables... This requires a table level lock with sqlite... FS does have some
things built in to handle this, but under load this can cause the switch to
appear to hang.<BR><BR>Switching over to use something like Postgresql (my
prefered db) helps out a good bit here, but keep in mind that in doing so you
greatly increase the resources required for the db. Also don’t forget that pgsql
has a similar mechanism on how it handles updates, just don’t forget to enable
auto-vacuuming on pgsql... That is a discussion for a different list
tho<BR><BR>K<BR><BR><BR>
<HR align=center width="95%" SIZE=3>
<B>From: </B>Brian West <brian@freeswitch.org><BR><B>Reply-To:
</B><freeswitch-users@lists.freeswitch.org><BR><B>Date: </B>Tue, 12 Aug
2008 13:24:40 -0500<BR><B>To:
</B><freeswitch-users@lists.freeswitch.org><BR><B>Subject: </B>Re:
[Freeswitch-users] Performance bottleneck<BR><BR>Well putting the db in ram does
help a bit but it has to keep states of everything going on and do extra work
for that... its a heavy task in itself.<BR><BR>On Aug 12, 2008, at 1:19 PM,
Michael Collins wrote:<BR><BR></SPAN></FONT></FONT>
<BLOCKQUOTE><FONT size=4><FONT color=#000080><FONT face=Arial><SPAN
style="FONT-SIZE: 10pt">That begs the question… is there a mechanism in sqlite
or Linux that allows for the RAM drive to be backed up periodically?
That would be a cool feature to get documented for those power users
like Ken!
;)<BR> <BR>-MC<BR> <BR></SPAN></FONT></FONT></FONT></BLOCKQUOTE><FONT
size=4><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt"><BR> <BR></SPAN></FONT></FONT><FONT
face="Helvetica, Verdana, Arial"><SPAN style="FONT-SIZE: 9pt">Brian
West<BR>sip:brian@freeswitch.org<BR><BR><BR> <BR></SPAN></FONT><FONT
size=4><FONT face="Calibri, Verdana, Helvetica, Arial"><SPAN
style="FONT-SIZE: 11pt"><BR><BR>
<HR align=center width="95%" SIZE=3>
</SPAN></FONT><FONT face="Consolas, Courier New, Courier"><SPAN
style="FONT-SIZE: 10pt">_______________________________________________<BR>Freeswitch-users
mailing list<BR>Freeswitch-users@lists.freeswitch.org<BR><A
href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</A><BR>UNSUBSCRIBE:<A
href="http://lists.freeswitch.org/mailman/options/freeswitch-users">http://lists.freeswitch.org/mailman/options/freeswitch-users</A><BR><A
href="http://www.freeswitch.org">http://www.freeswitch.org</A><BR></SPAN></FONT></FONT></BODY></HTML>