JMeter: JDBC Deletes Not Consistent - jmeter

In JMeter (v2.13 r1665067), I'm using the tearDown Thread Group to delete all of the left-over records that remain after a test run.
The odd thing I can't quite figure out:
When the Thread Group is executed in isolation (i.e., by itself), I am able to see the left-over records are deleted from within the database.
When the Thread Group is run as part of the full run (i.e., the full end-to-end test plan), the left-over records are not deleted from within the database.
Looking in SQL Profiler, it "appears" the DELETE is sent, yet the records remain in the db. Could it be my Constant Throughput settings or some other timing? Can anyone shed any light on why this happens only during a full run?
In the Test Plan, the Run tearDown Thread Groups after shutdown of main threads is enabled.
Here's what is in my tearDown Thread Group:
JDBC Connection Configuration
Variable Name = myPool
Connection Pool Config
Max # of Connections = 10
Pool Timeout = 5000
Idle Cleanup Interval (ms) = 60000
Auto Commit = True
Transaction Isolation = TRANSACTION_SERIALIZEABLE
Connection Validation by Pool
Keep-Alive = True
Max Connections Age = 5000
Validation Query = null
JDBC Request 1
Variable Name = myPool
Query Type = Prepared Update Statement
DELETE FROM Foo
WHERE Foo.QualifierObjId IN
(SELECT Bar.ObjId FROM Bar WHERE Bar.DsplyName like '%myTest%');
JDBC Request 2
Variable Name = myPool
Query Type = Prepared Update Statement
DELETE FROM Bar WHERE Bar.DsplyName like '%myTest%';
JDBC Request 3
Variable Name = myPool
Query Type = Prepared Update Statement
DELETE FROM Master WHERE Master.DsplyName like '%myTest%';

Solution
If you are using multiple JDBC Connections spread across multiple Thread Groups, be sure to have unique Variable Names bound to each Pool. I was using "myPool" for each JDBC Connection (basically due to copy/paste) and it was causing the issue. (my bad!)
The solution is:
Thread Group 1, JDBC Connection Configuration, Variable Name = myFooPool
Thread Group 2, JDBC Connection Configuration, Variable Name = myBarPool
tearDown Thread Group, JDBC Connection Configuration, Variable Name = myTearDownPool
Creating unique variable names for each Pool provides clarity between each JDBC configuration and avoids issues such as mine. Hope this helps someone else.

Related

JMeter Refer to two different databases in one Test Plan

I want tо refer to two different databases in one sql server in my Test Plan.
I have one Thread Group and 20 steps/samplers, and I want for the first 4 samplers all queries to database to be connect to 'database1' for example and others from step 5 to step 20 all queries are refered to 'database2'.
When I add JDBC connection configuration and try to change dynamically just DatabaseName JMeter accepts the first filled databaseName. For example: If I filled first 'database1' as a name all my connections to databases are to this 'database1' independently from that I change the value of DatabaseName adding new value of the variable 'database'.
I use something like:
jdbc:sqlserver://something.database.windows.net;DatabaseName=${database}
JDBC connection configuration is loaded once before test executed, as other JMeter's configurations
So you must have 2 JDBC connection configurations for each database with 2 different variable names
In JDBC request you can use different variable name when using different database pool names

Jmeter test database read performance

I am going to test database read performance with Jmeter Java Sampler.
Basically, query database 10000 times with primary key as query condition like ID with Thread group and Java Sampler.
I need to load 10000 records into database before executing the Thread Group.
The 10000 records will be looped for the 10000 times database read.
I have looked into the preprocessor of Jmeter. I can insert 10000 records into database in preprocessor, but I do not know how to pass the 10000 IDs to Thread Group or Java Sampler. It is too long to contact IDs as a String parameter.
How I can archive the purpose? Any comment is welcome.
Instead of inserting the data using PreProcessor I would rather recommend preparing the test data in setUp Thread Group. You can write the generated IDs into a file using i.e. Flexible File Writer and then read them back with the CSV Data Set Config
If the database you're testing supports JDBC protocol it makes more sense to use JDBC Request sampler because JDBC Connection Configuration allows using connection pool pattern which most probably your application will be using when talking to the database, the main idea is to set up JMeter to produce the same footprint as the application which will be accessing the database.

Failed login attempts in Oracle within what time frame?

I'm trying to configure a C3P0 JDBC connection pool to avoid locking an Oracle DB. Seems like acquireRetryAttempts and acquireRetryDelay are important.
Looking at Oracle 12c docs, I see:
FAILED_LOGIN_ATTEMPTS
Specify the number of consecutive failed attempts to log in to the user account before the account is locked. If you omit this clause, then the default is 10 times.
Within what time frame do the 10 attempts apply? I.e. if I set acquireRetryAttempts to 9, what value of acquireRetryDelay will avoid locking the DB?
You are asking for a time frame after which Oracle will forget about previous invalid login attempts? There is none.
Oracle maintains a column lcount in the SYS.USER$ table that has the number of consecutive invalid login attempts. It is only reset to zero upon a successful login.
If you don't want to lock the database accounts for too many failed password attempts, why don't you set failed_login_attempts to UNLIMITED for the profile your connection pool uses?
Oracle has Universal Connection Pool (UCP) that is feature rich and provides HA capabilities out of the box. So, you could consider using UCP.
Also, RETRY_DELAY and RETRY_COUNT can be used as connection descriptors as shown.
(DESCRIPTION =
     (CONNECT_TIMEOUT=90) (RETRY_COUNT=20)(RETRY_DELAY=3) (TRANSPORT_CONNECT_TIMEOUT=3)
      (ADDRESS_LIST =
(LOAD_BALANCE=on)
( ADDRESS = (PROTOCOL = TCP)(HOST=primary-scan)(PORT=1521)))
(ADDRESS_LIST =
(LOAD_BALANCE=on)
( ADDRESS = (PROTOCOL = TCP)(HOST=secondary-scan)(PORT=1521)))
(CONNECT_DATA=(SERVICE_NAME = gold-cloud)))
RETRY_COUNT:It specifies the number of network connect retry attempts before returning a failure message to the client. In the example above, Oracle Net retries 3 times before returning an error message to the client. This helps in increasing the possibility of getting a connection and thus improves the performance.
RETRY_DELAY:This parameter specifies the wait time in seconds between reconnection
attempts. It works in conjunction with RETRY_COUNT. So, it is advised to use RETRY_DELAY and RETRY_COUNT together to avoid unnecessary CPU cycles

JMeter: How to benchmark data deletion from database table in batches?

I am trying to compare the performance difference between DELETE batch sizes using JMeter.
I have a table which I populate with a large amount of test data. Next, I have a JDBC Request that runs the following statement:
delete from tbl where (entry_dt < '2019-02-01') and (rownum <= 10000);
I want to keep running this until the table is empty, and record the time taken to clear the table.
I will run this thread multiple times to get an average execution time, and repeat this process for different batch sizes.
How should I define my While Controller to achieve this?
I read from other sites that I can use a Transaction Controller to time my process, but I am not familiar with this feature. How should I define my Transaction Controller to achieve this?
Add Transaction Controller to be a top level test element under the Thread Group
Add While Controller as a child of the Transaction Controller and use the following condition expression:
${__jexl3(${count_1} > 0,)}
Put your JDBC Request sampler as a child of the While Controller
Add JDBC PostProcessor as a child of the JDBC Request sampler and configure it like:
That's it, While Controller will iterate until there are entries in the tbl table and the Transaction Controller will record the cumulative time of all JDBC Request samplers executed.
I would do it this way:
Use the "JDBC Request - Get Count" sampler to get the data from the db which has to be deleted
Use a BeanShell Assertion to check if there is more data that can be deleted. Otherwise stop the thread
Execute the request to delete the data
Thread Group should stop Test on error

Oracle IDLE sessions

We are having an issue with connections staying idle in Oracle. To give you some background, our users connect to Denodo which in turn has a data source that connects to Oracle. This data source works with one user name and password and creates a pool. The pool has an initial size of 4 and a Maximum number of active connections of 20.
Connections start coming in from clients using JDBC, ODBC and so on. Some clients are other server requesting data (Spotfire and BusinessObjects), and others are just regular users that have developed scripts in R, python, C# and others. They can also connect with tools such as DBeaver. The Oracle user has settings to maintain up to 100 connections idle.
Now, users connect with their scripts and they have code (that we have checked) that opens a connection to Denodo, gets the data through a query, gets the data returned, and closes the connection to Denodo. Denodo in turns does the same and opens the connection to Oracle, passes the query from the client to Oracle, gets the data and relays it back to the client. And this is the part we are not too sure about. We were expecting Denodo to close the connection to Oracle and it does not. The connection stays open in Oracle and shows as idle. Eventually we have enough connections idle to fill up the quota set up for the User (100).
Based on this, we have done some tune up in Denodo with the connection to Oracle and applied these settings to the connection:
FETCHSIZE = 10000
BATCHINSERTSIZE = 200
VALIDATIONQUERY = 'SELECT COUNT(*) FROM SYS.DUAL'
INITIALSIZE = 4 #initial size of pool
MAXIDLE = 25 #max number of idle connections
MINIDLE = 5 #min number of idle connections
MAXACTIVE = 20 #max active in the pool
EXHAUSTEDACTION = 1
TESTONBORROW = true
TESTONRETURN = false
TESTWHILEIDLE = false
TIMEBETWEENEVICTION = 300000 #time between evictions in milliseconds
NUMTESTPEREVICTION = 10 #10 connections to be evaluated for eviction
MINEVICTABLETIME = 900000 #min evictable time in milliseconds
POOLPREPAREDSTATEMENTS = false
MAXSLEEPINGPS = 4
INITIALCAPACITYPS = 8
After applying this setting, we thought it would clear the idle connections. Problem is that it has not. You can see the connections start creeping in and it eventually fills up again and does not allow for any other connection.
What I would like to see is Denodo open the connection that it needs, use it and release it. Not keep a connection in Idle in Oracle. Oracle connections do not seem to be evicted ever and eventually they reach 100 again.
Any help would be appreciated

Resources