Cool, as for the startup, i wonder if you can instead of trying to insert into VCL_Init, try to do just, as part of the startup process hit a special URL to load the hash_Table. Or another possibility might be to load an external module, and in there, populate the hash.
On Mon, Mar 7, 2011 at 9:45 AM, David Helkowski <[email protected]>wrote: > vcl configuration is turned straight into C first of all. > You can put your own C code in both the functions and globally. > When including headers/libraries, you essentially just have to include the > code globally. > > I am not sure if there is any 'init' function when varnish is called, so I > was suggesting that > the hash be initiated by just checking if the hash has been created yet. > > This will cause a penalty to the first vcl_recv call that goes through; but > that shouldn't > matter. > > Note that I just passed a dummy number as an example to the custom config, > and that > I didn't show how to do anything in the custom function. In this example, > all custom > stuff would be in straight C. You would need to use varnish itself to > compile what config > you want and look at the C code it generates to figure out how to tie in > all your custom > configs.... > > eg: > > C{ > #include "hash.c" // a string hashing store/lookup libary; you'll need to > write one > // or possibly just use some freely available one. > hashc *hash=0; > > void init_hash() { > if( hash ) return; > hash.store( 'test.com', &test_com ); > // same for all domains > } > > void test_com( int n ) { > // custom vcl_recv stuff for domain 'test' > } > } > > sub vcl_recv { > C{ > char *domain; > // [ place some code to fetch domain and put it in domain here ] > if( !hash ) init_hash(); > void (*func)(int); > func = hash.lookup( domain ); > func(1); > > } > } > > On 3/7/2011 9:23 AM, AD wrote: > > but dont all the configs need to be loaded at runtime, not sure the > overhead here? I think what you mentioned seems like a really innovative > way to "call" the function but what about anyimpact to "loading" all these > configs? > > If i understand what you are saying, i put a "call test_func;" in > vcl_recv which turned into this in C > > if (VGC_function_test_func(sp)) > return (1); > if > > Are you suggesting your hash_table would take over this step ? > > Adam > > On Mon, Mar 7, 2011 at 8:02 AM, David Helkowski <[email protected]>wrote: > >> The best way would be to use a jump table. >> By that, I mean to make multiple subroutines in C, and then to jump to the >> different subroutines by looking >> up pointers to the subroutines using a string hashing/lookup system. >> >> You would also need a flag to indicate whether the hash has been >> 'initialized' yet as well. >> The initialization would consist of storing function pointers at the hash >> locations corresponding to each >> of the domains. >> >> I attempted to do this myself when I first started using varnish, but I >> was having problems with varnish >> crashing when attempting to use the code I wrote in C. There may be >> limitations to the C code that can be >> used. >> >> >> On 3/6/2011 5:39 PM, AD wrote: >> >> Hello, >> >> what is the best way to run an instance of varnish that may need >> different vcl configurations for each hostname. This could end up being >> 100-500 includes to map to each hostname and then a long if/then block based >> on the hostname. Is there a more scalable way to deal with this? We have >> been toying with running one large varnish instance with tons of includes or >> possibly running multiple instances of varnish (with the config broken up) >> or spreading the load across different clusters (kind of like sharding) >> based on hostname to keep the configuration simple. >> >> Any best practices here? Are there any notes on the performance impact >> of the size of the VCL or the amount of if/then statements in vcl_recv to >> process a unique call function ? >> >> Thanks >> >> >> _______________________________________________ >> varnish-misc mailing >> [email protected]http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> >> >> >> _______________________________________________ >> varnish-misc mailing list >> [email protected] >> http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >> > > > > _______________________________________________ > varnish-misc mailing list > [email protected] > http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc >
_______________________________________________ varnish-misc mailing list [email protected] http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
