Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello Team,
Is there a way to limit the throughput(kbytes/sec) to a specific number? The reason behind is the network bandwidth only supports 200 MB of bandwidth an when the throughput reaches close to that number, the replicate task fails with a communication link failure. Help will be appreciated.
Thanks,
Nabeel
Hi @nabeelaslam1994 ,
You cannot directly change the throughput value. But you can achieve this by tuning task settings.
Thanks,
Swathi
Transaction consistency timeout only pertains to how long the task waits for pending transactions on the source to commit or roll back before starting the full load phase of a task. It will not affect network saturation.
First, I think this might be best handled my our Professional Services team. More information can be found here: How and when to contact Qlik's Professional Servic... - Qlik Community - 1714936
Is the limitation between Replicate and the source, or Replicate and the target? Or both? If the source, it will be dependent on the volume of changes in the tables on the source (during the change processing phase of the task). During the full load phase of the task, reducing the max number of tables on the Full Load Tuning page might help, but I'm not sure - there would be fewer tables selected from in parallel from the source, but it may not reduce the amount of data that flows from the source at one time - that will depend on how fast the select query runs at the source - and I expect it will try to use as much network bandwidth as it "needs".
If the limitation is between Replicate and the target, you might experiment with sending smaller batches of data to the target more often. These settings are found on the Change Processing \ Change Processing Tuning page in task settings. More information on using these settings can be found here: General understanding of Qlik Replicate Change Pro... - Qlik Community - 1937341
I hope this helps!
Dana
Hi @nabeelaslam1994 ,
You cannot directly change the throughput value. But you can achieve this by tuning task settings.
Thanks,
Swathi
Does 'Transaction consistency timeout(seconds)' will do it? What does it do?
Nabeel
Transaction consistency timeout only pertains to how long the task waits for pending transactions on the source to commit or roll back before starting the full load phase of a task. It will not affect network saturation.
First, I think this might be best handled my our Professional Services team. More information can be found here: How and when to contact Qlik's Professional Servic... - Qlik Community - 1714936
Is the limitation between Replicate and the source, or Replicate and the target? Or both? If the source, it will be dependent on the volume of changes in the tables on the source (during the change processing phase of the task). During the full load phase of the task, reducing the max number of tables on the Full Load Tuning page might help, but I'm not sure - there would be fewer tables selected from in parallel from the source, but it may not reduce the amount of data that flows from the source at one time - that will depend on how fast the select query runs at the source - and I expect it will try to use as much network bandwidth as it "needs".
If the limitation is between Replicate and the target, you might experiment with sending smaller batches of data to the target more often. These settings are found on the Change Processing \ Change Processing Tuning page in task settings. More information on using these settings can be found here: General understanding of Qlik Replicate Change Pro... - Qlik Community - 1937341
I hope this helps!
Dana
Hello @nabeelaslam1994 ,
Totally agree with Dana, additional comments:
1- we may control the Network Bandwidth Usage by OS utilities (on Windows or Linux), or 3rd party apps (eg control the incoming/outgoing bandwidth in VMWare)
2- please keep in mind that if limit the throughput, latency may build up in CDC stage
3- PS team can provide comprehensive analysis and proposal/solutions.
Regards,
John.