We're not using the SSL plugin yet, however what was your issue re the stabilty with Virtual Users, as this is causing us a major headache? - Not to mention not being able to use Persistant Connections or able to rely on the log file for accurate information!
Having extensively used QALoad 4.71, 4.72 (and now 4.8) every day since last November, I don't think that the SSL module is causing stability problems -- I get stability problems with or without it.
I have run upto about 400 users with the SSL module in. I get about a 10% loss of VUs when I run in process mode -- if I run in thread mode I lose whole players at a swipe. I suspect my problems lies in my scripting - C memory leaking -- I generic messages about memory or middleware erros.
Basically, I'm having to rely on process mode to get by, despite the large player processing overheads - I've just put an order in for £6K of new player hardware.
My scripts have been created using the WWW easyscript middleware, but I have to use at least one WSK function - Escapestr as my site uses binary HTTP POSTs with null characters embedded. I'm still experimenting with my own header files / local function combinations to get the best stability.
The less I ask my sripts to do in terms of parameterisation the more reliable they are.
I'm hoping 4.8 with it's improved player/conductor communications might make things more reliable.
I have used QALoad 4.8 with SSL to load tests web sites to upto 350 concurrent users. I have experienced VU drop outs and long page build times. When investigating the cause have found web server CPU running at 100%.
Investigation has shown that SSL is a highly CPU intensive task that can cause queueing in the web server and that when enough messages are queued, the webserver drop threads for inactive tasks. I saw 125 VU's dropped at one time.
In my case, the cause of this was that the web page being requested has .GIF and .JPG files on it, hence each page had to do multiple sub-requests to build the page. Due to the nature of SSL each .JPG and .GIF will be encrypted differently every time it is requested, hence it can't be stored in cache.
Removing/reducing the number of images on each page improved the page build times, the stability of the number of VU's and the number of completed pages/transactions.