sorry, I meant switch_xml_parse_str() not switch_parse_xml_from_str() Cristian Talle wrote: > 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 > > ============================================================================ > > [EMAIL PROTECTED]> 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 > > [EMAIL PROTECTED]> xml_curl cache_on > API CALL [xml_curl(cache_on)] output: > OK > > [EMAIL PROTECTED]> 2008-09-18 18:26:44 [CONSOLE] > mod_xml_curl.c:245 xml_url_fetch() Key is not in cache > [EMAIL PROTECTED] > 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: [EMAIL PROTECTED] > 2008-09-18 18:27:35 [CONSOLE] mod_xml_curl.c:231 xml_url_fetch() Using > xml from cache: [EMAIL PROTECTED] > > [EMAIL PROTECTED]> xml_curl cache_delete_key > [EMAIL PROTECTED] > 2008-09-18 18:27:42 [NOTICE] mod_xml_curl.c:128 xml_curl_function() > Removing value for [EMAIL PROTECTED] > API CALL [xml_curl(cache_delete_key [EMAIL PROTECTED])] output: > OK > > 2008-09-18 18:28:01 [CONSOLE] mod_xml_curl.c:245 xml_url_fetch() Key > is not in cache [EMAIL PROTECTED] > 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 > > [EMAIL PROTECTED]> 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 <[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]>> 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@lists.freeswitch.org >> <mailto:Freeswitch-users@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@lists.freeswitch.org >> <mailto:Freeswitch-users@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:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch >> >> FreeSWITCH Developer Conference >> sip:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> iax:[EMAIL PROTECTED]/888 >> <http://iax:[EMAIL PROTECTED]/888> >> googletalk:[EMAIL PROTECTED] >> <mailto:[EMAIL PROTECTED]> >> pstn:213-799-1400 >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> Freeswitch-users mailing list >> Freeswitch-users@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@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org