[Freeswitch-users] mod_cdr revival (or new module maybe)

[regs at kinetix.gr]

I'll try some tests with various combinations first and then decide 
what's best.

I have to say that I was astonished to find out that freeswitch had so 
many event handlers from the very beginning.
However it would be great if freeswitch had the options for extra 
functionality (auto log rotation, db cdrs etc)
so that it meets the peculiarities of every different project. That 
would make a big difference compared to
other softswitch solutions where the lack of such features prohibits 
people from using them (especially in
the carrier grade level). User feedback (and wish lists) is the key for 
the success of an open source (or not)
project...

Thank you all for your replies. You' ve been very helpful.

David Knell wrote:
> The sleep's done each time the directory's empty, not each time a 
> file's written.  File open and close
> are trivial (it's probably still cached), and the contents are going 
> to have to be parsed wherever you
> process it.
>
> We've used exactly this to process deliver CDRs on boxes handling in 
> excess of 500K mins/day
> without issue.  And, looking at one now, the CDR processor's used 
> about 4% of the CPU time
> of FreeSWITCH, and about half that of the MySQL database which it 
> writes the records to, also
> on the local machine, from which they're simply copied to the main CDR 
> processor.
>
> It performance simply isn't worth worrying about.
>
> --Dave
>> "sleep for a couple of seconds"
>>
>> But then you could only insert 1800 cdrs per hour...
>> If I was to insert 36000 cdrs per hour this means that I have to
>> open
>> parse
>> close
>> 10 files per second. Imagine the I/O penalty just for opening - closing the file.
>> (the persing is the same for both situations)
>>
>>   
>>
>>
>> David Knell wrote:
>>> regs at kinetix.gr wrote:
>>>   
>>>> Yes, the xml files give you tons of info... but isn't it a little 
>>>> insufficient - performance wise -
>>>> to open and close so many files in such a little time. In a PBX 
>>>> environment that wouldn't be an
>>>> issue but if we get to the small-voip-carrier level (some thousand cdrs 
>>>> per hour)
>>>> that could slow things down considerably, wouldn't it?
>>>>   
>>>>     
>>> Not that you'd notice.  We run XML CDR to database scripting on each box 
>>> that we use
>>> for switching, and it's a pretty trivial task compared with switching 
>>> all that media.  Doing it
>>> this way is:-
>>> (a) distributed - one process per box scales nicely;
>>> (b) robust - script down, DB down, no problem: files just queue up;
>>> (c) simple - the script logic is trivial:
>>> - while 1
>>>   - for each file in the XML CDR directory
>>>     - open it
>>>     - parse it (XML::Simple for us)
>>>     - insert it in to the DB
>>>     - delete it
>>>   - sleep for a couple of seconds
>>> Two error cases: can't parse or can't find data which should be there: 
>>> move the file in to
>>> another directory to be examined by real eyes; DB insert fails: break 
>>> out of inner loop and
>>> it'll be retried after a short pause.
>>>
>>> --Dave
>>>
>>>   
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Freeswitch-users mailing list
>> Freeswitch-users at lists.freeswitch.org
>> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
>> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
>> http://www.freeswitch.org
>>   
>
>
> -- 
> David Knell, Director, 3C Limited
> T: 020 8114 8901  F: 020 3002 7257  M: 001 415 630 3031
> http://www.3c.co.uk 
> ------------------------------------------------------------------------
>
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at lists.freeswitch.org
> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users
> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users
> http://www.freeswitch.org
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.freeswitch.org/pipermail/freeswitch-users/attachments/20081030/ca63b3c3/attachment-0002.html