single VS distributing new connections across multiple pools with persistence

We have a single VS in standard mode with 2 pools of servers. Each pool contains different servers.

VS has cookie insert persistence with named cookie and a 17min timeout.

Goal is to have 1 out of every X number of NEW connections only go to the second pool. Once a client has been sent to the second pool, the subsequent requests from that user should also follow into the the second pool if during same session.

We have a single global variable that increments each time HTTP_REQUEST occurs, but we want to modify this so that it only increments on new connections

Current rule:

   
 when RULE_INIT {   
     set ::cnt 0   
 }   
 when HTTP_REQUEST {   
     incr $cnt   
     if { $cnt = 4000 } {   
         set ::cnt 0   
         pool pool2   
     } else {   
       pool $pool1   
     }   
 }   
 

Pool 2 is about 20% of the capacity of Pool 1 and using different class of server hardware.

One thing that I was thinking of was to look for the named persistence cookie, and if it does not already exist then increment the global var

The assumption is that new/initial HTTP connections can be identified in the VS's iRule by looking for the presence of the named inserted cookie via the persistence profile.

We have the megaproxy issue so we are dependent on cookie inserted persistence

Possible changed rule

   
 when RULE_INIT {   
     set ::cnt 0   
 }   
 when HTTP_REQUEST {   
     if { ([HTTP::cookie] exists "namedcookie_from_persistence_profile") } {     
         send connection to existing persisted server in whichever pool its in   
         Can 'persist' just be used or does the member and pool need to be looked up and then    
         manually pooled there?   
     } else {   
          Assumption is only brand new initial connections with no persistence yet defined are    
          being dealt with at this point   
         incr $cnt   
         if { $cnt = 4000 } {   
             set ::cnt 0   
             pool pool2 New persistence record is formed after this 'pool'   
         } else {   
             pool $pool1   
         } 
     }   
 }   
 

Is this the right strategy?

Can 'persist' be used in place of 'pool' to make sure the specific member in the respective pool is reused for the rest of that sessions http requests? Or is 'pool' required to actually farm the connection out

What we are trying to avoid is having User Bob come in and hit homepage on global var cont 3998, go to a server in pool a, then click on 2 links and the second link sets the global var to 4000, which causes Bob to have his second click "pooled" to the second pool. Rather we would not want User Bob's subsequent http requests to be capable of incrementing that global var, so that when User Joe comes in on new connection and he trips the counter to 4000, then his requests and subsequent requests in same connection/session go to that same node in the second pool

Once the persistence cookie expires then the user can be sent to either of the pools.

If the node in the pool is marked down by a monitor, we would expect that to wipe out the named persistence cookie causing them to be free to be subject to new pool and new subsequent persistence record being created

Thanks for the help