Lots of configs

[David Helkowski]

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 <dhelkowski at sbgnet.com 
> <mailto:dhelkowski at sbgnet.com>> 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 list
>>     varnish-misc at varnish-cache.org  <mailto:varnish-misc at varnish-cache.org>
>>     http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>
>     _______________________________________________
>     varnish-misc mailing list
>     varnish-misc at varnish-cache.org <mailto:varnish-misc at varnish-cache.org>
>     http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.varnish-cache.org/lists/pipermail/varnish-misc/attachments/20110307/f249ef64/attachment-0003.html>