Found it, I think, via mcrypt performance:
The encryption class mentioned above uses MCRYPT_DEV_RANDOM as its random generator. Unfortunately (this is me summarizing the article), if /dev/random's pool runs out, it'll block the process until it's filled up again. If you can live with slightly lower-quality randomness, /dev/urandom will be faster and won't have this problem. Thus a change in the class from MCRYPT_DEV_RANDOM to MCRYPT_DEV_URANDOM should make things better, and my tests so far suggest that's true.