1. 15 Jun, 2008 16 commits
  2. 14 Jun, 2008 2 commits
  3. 11 Jun, 2008 2 commits
    • Poul-Henning Kamp's avatar
      Add an optional shortcut: · de2fd54b
      Poul-Henning Kamp authored
      The parameter session_linger determines how many milliseconds the
      workerthread waits to see if another request has arrived, before
      handing the session over to the session herder.
      
      If we manage to catch the next request this way, we save a number
      of semi-expensive steps, if we hang around too long, the worker-thread
      gets to goof off.
      
      A relatively small sample of data from a live server, indicates
      that 20% of all requests arrive within 50 msec of the previous
      request and 50% within 100msec.
      
      It is not clear at present how these timeintervals relate to client
      RTT, or if they are systematically too high, due to the duration
      of the detour over the herder.
      
      There is a new line in varnishstat keeping track of how many times
      this gamble succeeds.
      
      Experimentation is encouraged.
      
      
      
      
      git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2663 d4fa192b-c00b-0410-8231-f00ffab90ce4
      de2fd54b
    • Poul-Henning Kamp's avatar
      Be a little less hysteric with charging session statistics to · 994cde5a
      Poul-Henning Kamp authored
      srcaddr and global counters.
      
      
      git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2662 d4fa192b-c00b-0410-8231-f00ffab90ce4
      994cde5a
  4. 10 Jun, 2008 2 commits
  5. 09 Jun, 2008 5 commits
  6. 08 Jun, 2008 1 commit
  7. 07 Jun, 2008 1 commit
    • Poul-Henning Kamp's avatar
      Redo the way we manage the thread pool(s). · ea859f03
      Poul-Henning Kamp authored
      This is necessary to generalize the thread pools to do other tasks
      for us in the future.
      
      Please read the descriptions of the new and changed thread_pool*
      parameters carefully before you tweak them, some of them have
      slightly different meanings now.
      
      The high-level view of this is that we now have dedicated a thread to
      adding threads to the pools, in addition to the thread we already
      had that killed idle threads from the pools.
      
      The difference is that this new thread is quite a bit more reluctant
      to add threads than the previous code, which would add a thread any
      time it could get away with it.
      
      Hopefully that reduces the tendency for thread-pile-ups.
      
      This commit also reduces the cross-pool locking contention by making
      the overflow queue a per pool item.
      
      The down side of that is that more of the stats counters have become
      unlocked and thus can get out of sync if two threads race when updating
      them.  This is an XXX item.
      
      Thanks to Anders Nordby for testing this patch.
      
      
      
      
      git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2653 d4fa192b-c00b-0410-8231-f00ffab90ce4
      ea859f03
  8. 06 Jun, 2008 2 commits
  9. 05 Jun, 2008 4 commits
  10. 02 Jun, 2008 1 commit
  11. 31 May, 2008 2 commits
    • Poul-Henning Kamp's avatar
      · e5d00cf7
      Poul-Henning Kamp authored
      Overhaul the regexp purge/ban code, with a detour around the CLI code.
      
      
      CLI code:
      
      	In CLI help, don't list commands with no syntax description.
      
      	Add a CLI_HIDDEN macro to construct such entries.  They are
      	useful as backwards compatibility entries which we do not want
      	to show in the help.
      
      CLI interface to BAN (purge) code:
      
      	Get the CLI names right for purging so they are purge.FOO instead
      	of FOO.purge.
      
      	This means that you should use "purge.url" and "purge.hash"
      	instead of "url.purge" and "hash.purge".
      
      	Add compat entries for the old, and keep them through the 2.x
      	release series.
      	
      
      	Add purge.list command to list purges currently in effect.
      	NB: This is not 100% locking safe, so don't abuse it.
      
      
      BAN (purge) code:
      
      	Add reference counting and GC to bans.
      
      	Since we now have full reference counting, drop the sequence
      	number based soft references and go to "hard" pointer
      	references from the object to the purges.
      
      	Give the "ban" structure the miniobj treatment while we are
      	at it.
      
      	The cost of this is a lock operation to update refcounts
      	once all applicable bans have been checked on an object.
      
      	There is no locking cost if there is no bans to check.
      
      	Add explicit call to new BAN_DestroyObj() when objects are
      	destroyed to release the refcount.
      
      	When we release an object refcount in BAN_DestroyObj(),
      	check if we can destroy the last purge in the list also.
      
      	We only destroy one ban per BAN_DestroyObj() call, to avoid
      	getting stuck too long time, (tacitly assuming that we will
      	destroy more objects than bans.)
      
      
      
      git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2645 d4fa192b-c00b-0410-8231-f00ffab90ce4
      e5d00cf7
    • Poul-Henning Kamp's avatar
      Go over the Telnet/CLI code in the manager process. · 3a5d621c
      Poul-Henning Kamp authored
      Implement "quit" (ticket 125) and drop the planned aliases.
      
      Add CLIS_CLOSE return status, to communicate that close is happening.
      
      Fix logical bug in fd-table allocation bug in event-engine.
      
      Plug memory leak in CLI session destruction.
      
      Increase listen depth of telnet socket to 10.
      
      Ignore trailing whitespace and empty CLI input lines.
      
      Log CLI sessions and commands into syslog.
      
      
      
      git-svn-id: http://www.varnish-cache.org/svn/trunk/varnish-cache@2644 d4fa192b-c00b-0410-8231-f00ffab90ce4
      3a5d621c
  12. 30 May, 2008 2 commits