Vuser scripting for web.
Ok now you got an application to performance test, you have recorded vuser scripts correlated it perfectly. And the scripts run perfectly in the controller with multiple users.
You have designed the required scenario, you also get response times. Great. Now you will assume that scripts ran successfully and response times are correct. NO. there is a catch.
Moving on….
Say you have an application where you enter the shipping number and date and submit.
So you will be directed to a page where you no longer be able to edit the information according to a business rule for a particular order.
You record the script and replay it. If you succeed you are missing something. Are you verifying whether the DML statements are getting executed on the database server, if not then chances are that you are not applying load to the database server. When you submit a request, your web server passes on the information to database. Two things happen here DML statements for inserts, updates and DDL statements to read and display the results on the webpage.
According to business rule you cannot enter shipping number and shipping date twice. Its disabled from UI.Since vuser is not UI based. If you replay the script, the vuser will run successfully. It makes no difference to the webserver. But database will not execute the dml statements because a business logic rule is defined here. So it just executes READ and sends the data back to the user. So, this is how results may not be accurate.
So how do you find out this…
REDgate SQL log rescue. Or Apex log reader sql tools will read the logs on the sql server. You can see if any transactions happened. These tools were also useful to know how many of data tables are you hitting by using your virtual users. One more advantage was you can rollback the transactions you did. This implies less data staging. Now once we get to the tabular level of detail, there are numerous ways you can find out what kind of deadlocks or blocking will occur.
