The bcrypt rounds are indeed expensive and ClientState should hold the result for the active connection. So it sounds like you are creating a lot of new connections and thus hitting that bcrypt penalty.
On Wed, Aug 21, 2013 at 12:28 PM, Joshua M. Thompson < joshua.thomp...@gmail.com> wrote: > Hello, > > I've been tasked with tuning a Cassandra-based app for eventual production > deployment and I'm running into an issue I can't seem to solve when I run > my load tests. I'm still relatively new to Cassandra so i'm hoping there is > something obvious I'm missing here. > > Basically, everything runs great as long as authentication is disabled > (using the AllowAll* modules.) In that configuration CPU usage on the > application servers and the Cassandra servers is minimal. But as soon as > enable authentication the CPU usage on the Cassandra nodes shoots up to > around 150% on all nodes, and any requests to the application that make > Cassandra calls have an increase in response time of ~500 ms. Application > server load remains unchanged, however. > > The application is a PHP app using phpcassa, and running under PHP-FPM. > Connection pooling is turned on, but being a PHP app this only goes so far. > There are three Cassandra nodes running 1.2.8, on 8-CPU, 16 GB ESX > instances. Each node is on a different ESX host. > > By every metric I have checked the actual read/write response time on the > cluster is very fast; it's just the authentication that seems to bog things > down. Is logging into a Cassandra instance really that CPU intensive? >
