Update taking time on Test instance more compared to dev

Akki1
Tera Contributor

Hi,

If I try to update bulk records through one of the script in one of the custom table then in QA it takes a lot of time .

Example : If I update 3000 records on Dev it takes 1 minute or less but the same on QA takes 30 minutes.

Also, I tried to just delete top 3000 records through Background scripts that too takes 30 minutes

2 REPLIES 2

msd93
Kilo Sage

Hi @Akki1 

The difference in time taken to update records between Dev and QA environments could be due to several reasons:

 

1. **Server Load**: The QA environment might be handling more load compared to the Dev environment. This could be due to more users, more processes running, or more data to handle.

2. **Database Size**: The size of the database in the QA environment might be larger than the Dev environment. Larger databases take more time to update.

3. **Network Latency**: If the QA environment is located in a different geographical location than the Dev environment, network latency could be a factor.

4. **Hardware Differences**: The hardware (CPU, RAM, Disk I/O, etc.) of the servers hosting the QA environment might be less powerful than those hosting the Dev environment.

5. **Indexing**: The database in the Dev environment might be better indexed than the QA environment. Indexing can significantly speed up data retrieval and update times.

6. **Data Fragmentation**: Over time, databases can become fragmented, slowing down performance. The QA database might be more fragmented than the Dev database.

 

To reduce the time to update 3000 records, you could:

 

1. **Optimize the Database**: Regularly defragment the database, update statistics, and reorganize indexes.

2. **Upgrade Hardware**: If the server hardware is the bottleneck, consider upgrading to more powerful hardware. 3. **Optimize Network**: If network latency is an issue, consider optimizing the network or moving the QA environment closer to the users.

4. **Load Balancing**: Implement load balancing to distribute the load among multiple servers.

5. **Batch Updates**: Instead of updating all 3000 records at once, consider updating them in smaller batches.

6. **Optimize Code**: If the code that's updating the records is inefficient, consider optimizing it.

7. **Parallel Processing**: If possible, consider updating records in parallel rather than sequentially.

 

Hope this info helps you.

Rhodri
Tera Guru

In addition to the other reply, I'd recommend running this either in a fix script or a scheduled job (with a one time execution) that way you aren't adversely affected by the runtime and you can let it execute in the background.