vers. 10.1 "session" table limits and monitoring

Didn't sparkie or someone put some details in one of the tables tutorials previously? Let me take a quick look.

 

 

H

Yep it was spark who wrote the table docs (Hard to find. It took me a while, the table command isn't documented in the iRules wiki that I can find. The article is at http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2375)

 

 

However I can't find the article I remember seeing that gave an indication on how much memory each table entry used... From memory you can see the information from tmctl counters somewhere... So assuming we can find which counter it is, we could write an iRule to create X thousand entries and then check that... And X more... And check again, to give a graph of how much memory for X number of table entries.

 

 

H

 

 

H

Hi Hamish,

 

 

The table wiki page is in the standard format for all iRule wiki pages:

 

 

http://devcentral.f5.com/wiki/default.aspx/iRules/table

 

 

And there is a link on the wiki page to the series of table articles.

 

 

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2375

 

 

And here's one notable section:

 

 

 

http://devcentral.f5.com/Default.aspx?tabid=63&articleType=ArticleView&articleId=2382

 

 

Limitations

 

 

As fantastic as the new session table is, it does have its limitations. You can't use the table command in RULE_INIT or any other global event. There's no way to access the session table outside of tmm. The ability to count and list keys is limited to subtables. Timestamps are limited to 1-second resolution, so there's no way to do counts for sub-second events.

 

 

As you saw, you can use it for accurate counting, but that's not nearly as easy to use as we'd like it to be. We tried very hard to come up with a command, or set of commands, that would hide all the table manipulation and just do the counting for you, but everything we came up with was either very complicated or would always use the most computationally expensive method for counting, and that seemed like a bad tradeoff.

 

 

 

Aaron