Best practices to improve AIQ performance

Consider the following factors to improve AIQ performance.

• Split test assets in more than one repository project
  The size of the repositories should be manageable. Repositories should not be too big as each user clones its repo in a user-related folder in the controller.
  Specifically, the AI team should have a repository separate from teams that do not work with AI. Each saved blueprint contains a lot of files, including images, that can significantly affect the performance of other users opening and saving files.
  

• Team members should only have the required repositories
  Individual user repositories impact the general controller performance. Users must manage their repositories to ensure only the required ones are present and properly configured. Any repository configurations that fail because of incorrect credentials should be fixed or deleted.
  

• Minimal latency between the controller and git the repository server
  In some closed networks, the network security configuration can make the connectivity with external git repositories slow. Increased latency greatly impacts user experience waiting for repo synchronization when saving files.
  

• MySQL database should be a separate instance
  The MySQL database has stored procedures that are used to process some of the results data. It is recommended that you have the MySQL service installed in a different instance than the controller, such as an AWS RDS.
  

• Controller should be located in the same geographical region/zone as the users
  Whenever possible, the controller and the users should be in the same geographical location. Doing so will reduce any connection lag. For example, if the controller is in a US region, and the testing team is in London or Australia, there will be a significant lag in the connection.
  

• Controller, test nodes, and RDS database should be located in the same geographical region/zone
  Whenever possible, the servers should be in the same geographical location. This will help in reducing the time required to save test results and improve the general performance of the infrastructure.
  Note: If the controller is experiencing latency issues with commits to the DB then the RDS should have a higher IOPS storage rating. A minimum of 6000 IOPS is recommended.
  

• VPN configuration
  VPNs can slow down communication between the local computer browser and the AIQ controller. Check with your networking/security team to see if this can be improved. VPN server location could also impact AIQ Controller access. (See recommendations #5 and #6)
  

• Servers should have high-performance hard drive volumes.
  Hard drives of the controller and test nodes should have, at a minimum, 6000 IOPS (input/output operations per second) ratings. If possible, use hard drive with even higher ratings. The speed of the volumes significantly impacts the execution of the Test Designer’s browser-based test cases, Each browser writes its cache files to the volume, so slow hard drives risk creating bottlenecks when running performance tests.
  For the most efficient hard drive performance consider using NVME instance types and copy the aiq_distribution and graalvm folders to the SSD volume.
  

• Antivirus configuration
  Exclude AIQ-related folders (TestDesigner and aiq_distribution folders) in the controller, nodes, and local computers from the antivirus program. This can have a significant impact on performance because some antivirus programs slow down writing files to the disk.
  

• Performance scenarios should not log details to the database
  By default, the performance scenario setting for logging details is set to 10% of transactions. In some cases, this setting can still be too big for big performance tests. Reducing or even disabling logging any details to the database will make the scenario tear-down process faster.
  

• Remove users that are not longer active
  Users that has left the company or will not be using AIQ anymore should be removed from the AIQ controller user configuration as their configured repositories will keep being synchronized and taking disk space on controller.
  

• Enforce a maximum number of history builds in the CICD dashboard using housekeeping target.
  Everytime a CICD build is processed, the complete history of builds is traversed to create the history dashboard report. On CICD build.xml you can configure the housekeeping target to a maximum number of builds to keep (default is 50).
  

• Scenarios should handle dynamic requests with regular expressions.
  In the Reporting section on the Options tab of the Scenario Editor, there is an option called “Add Dynamic Parameter” that allows replacing dynamic values from test URLs using regular expressions, so the summaries can be calculated to all occurrences of that URL ignoring the dynamic parameter/path values. Failing to do this can cause long durations for scenario and CICD pipeline teardown specially in performance scenarios but also in functional scenarios with many test cases.
  

  

  
  It is very common that a timestamp be added to query parameters with an _ as the name of the parameter.
  For example:
  https://www.example.com/processuser?user=1&_=9684736251
  
  So you can create a regular expression to replace that dynamic value with some static value like the following: