Existem duas desvantagens principais:
Sua carga não é distribuída uniformemente. Sessões persistentes permanecerão, daí o nome. Embora as solicitações iniciais sejam distribuídas uniformemente, você pode acabar com um número significativo de usuários gastando mais tempo do que outros. Se tudo isso estiver definido inicialmente em um único servidor, esse servidor terá muito mais carga. Normalmente, isso realmente não terá um grande impacto e pode ser mitigado com a presença de mais servidores no cluster.
Os proxies conglomeram os usuários em IPs únicos, os quais seriam enviados para um único servidor. Embora isso normalmente não cause danos, além de aumentar as cargas individuais do servidor, os proxies também podem operar em um cluster. Uma solicitação para o seu F5 de um sistema desse tipo não seria necessariamente enviada de volta ao mesmo servidor se a solicitação sair de um servidor proxy diferente em seu cluster de proxy.
A AOL estava em um ponto usando clusters de proxy e realmente se ferrava com balanceadores de carga e sessões complicadas. A maioria dos balanceadores de carga agora oferecerá sessões autônomas baseadas em intervalos líquidos da classe C ou, no caso de F5, sessões autônomas baseadas em cookie que armazenam o nó final em um cookie de solicitação da web.
Embora as sessões baseadas em cookies funcionem, tive alguns problemas com elas e geralmente escolho as sessões baseadas em IP. GRANDE NO ENTANTO: estou trabalhando principalmente em aplicativos internos - a milhagem da DMZ pode variar.
Tudo isso dito, tivemos um grande sucesso com sites rodando o F5 com sessões complicadas e sessões In-Proc.
Você também pode querer dar uma olhada em um dos sistemas de cache distribuído na memória, como o Memcached ou o Velocity, como uma alternativa para a sessão ser armazenada no SQL ou no serviço de memória fora do proc. Você se aproxima da velocidade da memória em processo, com a capacidade de executá-la em vários servidores.
