[Freeswitch-users] Alternative to directory lookup using mod_xml_curl

Thu Sep 18 15:53:59 PDT 2008

I gave it a try though... and it works nicely (at least for directory 
entries for now). I've added 3 more commands to xml_curl: cache_on, 
cache_off and cache_delete_key.

- cache_on - enables caching: it will store in a switch_hash_t structure 
all xml strings returned by curl, using <username>@<realm> as a key 
(since we're talking directory only in this example). The same key is 
looked up every time the xml is requested for that user/realm and the 
code returns an xml structure created using switch_parse_xml_from_str().

- cache_off - switches back to the original behavior and clears the hash.

- cache_delete_key <key> - will invalidate the cache entry so that next 
time it is reloaded by curl.

considering a 500 bytes - 1K string for each profile, you can cache 
10000 user profiles in ~10M (considering we're storing the char* s)
please see a sample console output,with a terminal registering every 25 
seconds

============================================================================
freeswitch at localhost.localdomain> 2008-09-18 18:26:19 [CONSOLE] 
mod_xml_curl.c:363 xml_url_fetch() XML response is in 
/tmp/d0c586a8-85d0-11dd-838c-5148f6e85b7b.tmp.xml

freeswitch at localhost.localdomain> xml_curl cache_on
API CALL [xml_curl(cache_on)] output:
OK

freeswitch at localhost.localdomain> 2008-09-18 18:26:44 [CONSOLE] 
mod_xml_curl.c:245 xml_url_fetch() Key is not in cache [1039 at 192.168.1.225].
2008-09-18 18:26:45 [CONSOLE] mod_xml_curl.c:363 xml_url_fetch() XML 
response is in /tmp/e00c7ae0-85d0-11dd-838c-5148f6e85b7b.tmp.xml

2008-09-18 18:27:10 [CONSOLE] mod_xml_curl.c:231 xml_url_fetch() Using 
xml from cache: 1039 at 192.168.1.225
2008-09-18 18:27:35 [CONSOLE] mod_xml_curl.c:231 xml_url_fetch() Using 
xml from cache: 1039 at 192.168.1.225

freeswitch at localhost.localdomain> xml_curl cache_delete_key 
1039 at 192.168.1.225
2008-09-18 18:27:42 [NOTICE] mod_xml_curl.c:128 xml_curl_function() 
Removing value for [1039 at 192.168.1.225]
API CALL [xml_curl(cache_delete_key 1039 at 192.168.1.225)] output:
OK

2008-09-18 18:28:01 [CONSOLE] mod_xml_curl.c:245 xml_url_fetch() Key is 
not in cache [1039 at 192.168.1.225].
2008-09-18 18:28:01 [CONSOLE] mod_xml_curl.c:363 xml_url_fetch() XML 
response is in /tmp/0d729f00-85d1-11dd-838c-5148f6e85b7b.tmp.xml

freeswitch at localhost.localdomain> xml_curl cache_off
2008-09-18 18:28:07 [NOTICE] mod_xml_curl.c:102 xml_curl_function() 
cleaning up directory cache
API CALL [xml_curl(cache_off)] output:
OK
========================================================================

cristian

Anthony Minessale wrote:
> if you say inhale the xml into memory and the sever goes haywire and 
> sends you 2 gigs out output you are in for a treat.
> if you can get enough call volume on one box where the disk i/o of 
> xml_curl even shows up on the map in relation to all the rtp etc, 
> we've won.
>
>
> On Wed, Sep 17, 2008 at 6:00 PM, Cristian Talle <ctalle at voiceway.ca 
> <mailto:ctalle at voiceway.ca>> wrote:
>
>     less tickin keeps you breathin :) It'd be nice though if you could
>     just
>     use xml_rpc to tell FS:
>
>     /xml_update <section> <tag> <tag_attr_name> <tag_attr_val>...,/
>
>     similar to xml_locate
>
>     Cristian
>
>     Brian West wrote:
>     > If you're that concerned with it.. move the tmp to a ramdisk ;)  I
>     > thought modern hard drives could take a lickin and keep on tickin
>     >
>     > /b
>     >
>     > On Sep 17, 2008, at 5:51 PM, Cristian Talle wrote:
>     >
>     >
>     >> Oh, they are but it's still HDD... I wouldn't like to see the
>     server
>     >> die
>     >> because of too much disk IO
>     >> I'm trying to figure out what's the most efficient way to handle
>     >> changes
>     >> in user profiles (and possibly dialplan, etc...) if order handle
>     >> thousands of users per server.
>     >>
>     >> Cristian
>     >>
>     >
>     >
>     > _______________________________________________
>     > Freeswitch-users mailing list
>     > Freeswitch-users at lists.freeswitch.org
>     <mailto: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
>     >
>     >
>
>
>     _______________________________________________
>     Freeswitch-users mailing list
>     Freeswitch-users at lists.freeswitch.org
>     <mailto: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
>
>
>
>
> -- 
> Anthony Minessale II
>
> FreeSWITCH http://www.freeswitch.org/
> ClueCon http://www.cluecon.com/
>
> AIM: anthm
> MSN:anthony_minessale at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
>
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest@conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> ------------------------------------------------------------------------
>
> _______________________________________________
> 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
>   