Forum Discussion

Chris_Phillips's avatar
Chris_Phillips
Icon for Nimbostratus rankNimbostratus
Oct 11, 2012

subtable entry expiry

Howdy,

 

I've a rate limiting iRule that adds expiring entries to a subtable and blocks a request if the size of the subtable is over a certain limit. hopefully no more detail is actually required here...

 

What we've been seeing is that if we permit this rule to allow 200 requests per second what we actually experience is a throughput of 100, not 200. This appears to be because entries in a subtable are not actually removed until a second after the entry time out reaches zero.

 

it looks to us like the entries on a subtable are only removed (and maybe added??) once per second, on some sort of schedule, rather than entries gracefully removing at the millisecond that their timer expires.

 

Basically we've found that we need to factor in an extra second in our coding logic to get the desired behavior. So when we want to permit 1 request a second, we actually can specify 2 per second, (or 10 in 9 seconds) knowing that the extra second where the subtable entry sits there on zero seconds will be forced into the equation. We tried permitting 1 per zero seconds, however this resulted in nothing being permitted. This initially sounds pretty obvious, but seemed like a potential solution given this scheduling behavior, but here it looks as if the entry is added to the table and instantly removed, as if the same interrupt that removed the entry would also remove it.

 

So yeah, allowing 10 in 9 seconds gives 1TPS, 2 in 1 second gives 1TPS and this is totally down to the internals of the table expiration logic. And if someone can comment on that, that'd be good, as whilst this iRule worked perfectly in testing, slowly stepping through 10 requests in 60 seconds, now we want 200TPS, it's a very different story.

 

Thanks

 

Chris

 

application delivery
dev
devops
iRules

12 Replies

Sort By
Show More
  • spark_86682's avatar
    spark_86682
    Historic F5 Account
    Oct 25, 2012

    We're starting to get into implementation details now, rather than "the way it's defined to work", but it's checked on every direct access.

     

     

    I still get the feeling we're talking past each other a little. Here's some code to demonstrate what I mean:

     

     

    
   when CLIENT_ACCEPTED {
      table set key value 1
      set i 0
      while { $i < 20 } {
         set value [table lookup -notouch key]
         set time [clock clicks]
         set sec [string range $time 0 end-6]
         set msec [string range $time end-5 end]
         TCP::respond "At time $sec.$msec, value is $value\n"
         after 100
         incr i
      }
      TCP::close
   }

     

     

    And here's the output:

     

     

    
At time 1351212932.733766, value is value
At time 1351212932.832804, value is value
At time 1351212932.933246, value is value
At time 1351212933.032919, value is value
At time 1351212933.132832, value is value
At time 1351212933.233118, value is value
At time 1351212933.333066, value is value
At time 1351212933.432822, value is value
At time 1351212933.532911, value is value
At time 1351212933.632760, value is value
At time 1351212933.733043, value is value
At time 1351212933.833203, value is value
At time 1351212933.932783, value is value
At time 1351212934.033167, value is
At time 1351212934.132744, value is
At time 1351212934.232816, value is
At time 1351212934.332892, value is
At time 1351212934.432927, value is
At time 1351212934.532918, value is
At time 1351212934.633084, value is

     

     

    The entry was added at 1351212932 with a 1 second timeout, so when the current time minus 1351212932 exceeds 1, the entry gets expired. So an entry with a 1 second timeout is removed anywhere between 1 and 1.999999 seconds after it was added, depending on where in the second it was added.