There’s been a bit of buzz lately where MySQL databases have been compromised and user passwords being stored in plain text. Bad fu. It’s pretty simple to encrypt passwords in MySQL, here’s how you do it.
Read MoreA common requirement when load testing is to populate subsequent requests with dynamic data from previous requests. If you’re thinking about using a database to store static test data, such as usernames, paswords, credit card numbers etc then read on to find out how to extract this data at runtime and populate JMeter variables.
Read MoreWhen running multiple vuser groups with the same script i.e.

If that script references a data file (for parameters) then that data file is shared by *all* vuser groups.
e.g. my parameter called {values} has


When running, vuser group_b will error with these settings e.g.

So 2 separate vuser groups still equals one shared parameter file (and settings).
Watch out for this!
NOTE: This doesn’t generate a timestamp accurate to milliseconds. It just stores it in two fields. AFAIK there is no way to generate such a thing. It is accurately described here. Sorry for the confusion =)
Bug #8523 details MySQL’s deficiency in its ability to store and retrieve datetime values with millisecond or microsecond precision. When performance testing and perhaps storing trace logs or audit information in a MySQL table for later analysis, this shortfall is quite frustrating.
My hacky way to deal with this is to store the millisecond component as its own integer. Say for example you are interested in the difference between a Put datetime and Get datetime for MQ, your table might look like this:
CREATE TABLE `msecs` ( `put_datetime` datetime DEFAULT NULL, `put_msecs` int(11) DEFAULT NULL, `get_datetime` datetime DEFAULT NULL, `get_msecs` int(11) DEFAULT NULL ) ENGINE=InnoDB DEFAULT CHARSET=latin1;
So in this table I am storing the datetime component in its native MySQL format and the millisecond component as an integer. Here are some examples:

Now to retrieve and compare the values, I get the difference using TIME_TO_SEC for the datetime component, multiply it by 1000 to convert to milliseconds then add to the difference of the milliseconds component using basic maths:
SELECT ((TIME_TO_SEC(get_datetime) - TIME_TO_SEC(put_datetime))*1000) + (get_msecs-put_msecs) AS diff_msecs FROM msecs
That gives you difference in milliseconds for the demo table along these lines:
2300
1700
300
600700
700
Hopefully that makes sense. Pipe up if you have an easier solution!
Read MoreIf you are a rails fan you will probably recommend using active record instead, but if you just want to hack away at your mysql db from within your Ruby code, you may find this handy…
I’m currently using a wamp box to serve up content for performance metrics. What I needed was a Ruby script which could interrogate data on this installation.
You can download the binary required for this from here. After you install the gem (I do this off-line as my command prompt doesn’t allow me internet access here at work) you may find that you get an error similar to the following:
"NameError: uninitialized constant Mysql"
See what’s happening?
Read More
