<div>Hi David, List.</div><div><br></div>On Mon, Mar 7, 2011 at 7:52 PM, David Helkowski <span dir="ltr"><<a href="mailto:dhelkowski@sbgnet.com" target="_blank">dhelkowski@sbgnet.com</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


  
    
    
  
  <div bgcolor="#ffffff" text="#000000">
    A modern CPU can run, at most, around 10 million -assembly based-
    instructions per second.<br>
    See <a href="http://en.wikipedia.org/wiki/Instructions_per_second" target="_blank">http://en.wikipedia.org/wiki/Instructions_per_second</a><br>
    A regular expression compare is likely at least 20 or so assembly
    instructions.<br>
    That gives around 500,000 regular expression compares if you are
    using 100% of the<br>
    CPU just for that. A reasonable amount of CPU to consume would be
    30% ( at most ).<br>
    So; you are left with around 150k regular expression checks per
    second.<br></div></blockquote><div><br></div><div>I guess we should stop speculating. I wrote a short program to do in-cache pcre pattern matching. </div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>

My laptop (i5 M560) seems to churn through 7M pcre matches a second so I was a bit off. The matches where anchored and small but varying it doesn't seem to affect performance much. </div><div><br></div><div>The source for my test is here: <a href="http://pastebin.com/a68y15hp">http://pastebin.com/a68y15hp</a> </div>

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000">(.. )</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div bgcolor="#ffffff" text="#000000">
    Compare it to a hash lookup. A hash lookup, using a good minimal
    perfect hashing algorithms,<br>
    will take at most around 10 operations. Using the same math as
    above, that gives around 300k<br>
    lookups per second. A hash would be roughly 500 times faster than
    using if/else...</div></blockquote><div><br></div><div>Of course a hash lookup is faster. But if you got to deploy a whole bunch of scary inline C that will seriously intimidate the summer intern and makes all the other fear the config it's just not worth it. Of course it isn't as cool a building a hash table of functions in inline C, but is it useful when the speedup gain is lost in buffer bloat anyway? I think not.</div>

<div><br></div><div>Cheers,</div><div><br></div><div>Per.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#ffffff" text="#000000"><div>
<div>
</div><div><br>
    <br>
    On 3/7/2011 1:35 PM, Per Buer wrote:
    </div></div><blockquote type="cite"><div><div></div><div>
      <div>Hi,</div>
      <div><br>
      </div>
      On Sun, Mar 6, 2011 at 11:39 PM, AD <span dir="ltr"><<a href="mailto:straightflush@gmail.com" target="_blank">straightflush@gmail.com</a>></span>
      wrote:<br>
      <div class="gmail_quote">
        <blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
          <br>
          <div> 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?</div>
        </blockquote>
        <div><br>
        </div>
        <div>CPU and memory bandwidth is abundant on modern servers. I'm
          actually not sure that having a 500 entries long if/else
          statement will hamper performance at all. Remember, there will
          be no system calls. I would guess a modern server will execute
          at least a four million regex-based if/else per second per CPU
          core if most of the code and data will be in the on die cache.
          So executing 500 matches should take about 0.5ms.</div>
        <div><br>
        </div>
        <div>It might not make sense to optimize this. </div>
        <div><br>
        </div>
      </div>
      -- <br>
      Per Buer, Varnish Software<br>
      Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer<br>
      Varnish makes websites fly!<br>
      Want to learn more about Varnish? <a href="http://www.varnish-software.com/whitepapers" target="_blank">http://www.varnish-software.com/whitepapers</a><br>
      <br>
      </div></div><pre><fieldset></fieldset>
_______________________________________________
varnish-misc mailing list
<div><a href="mailto:varnish-misc@varnish-cache.org" target="_blank">varnish-misc@varnish-cache.org</a>
<a href="http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc" target="_blank">http://www.varnish-cache.org/lists/mailman/listinfo/varnish-misc</a></div></pre>
    </blockquote>
    <br>
  </div>

</blockquote></div><br><br clear="all"><br>-- <br>Per Buer, Varnish Software<br>Phone: +47 21 98 92 61 / Mobile: +47 958 39 117 / Skype: per.buer<br>Varnish makes websites fly!<br>Want to learn more about Varnish? <a href="http://www.varnish-software.com/whitepapers" target="_blank">http://www.varnish-software.com/whitepapers</a><br>


<br>