I re-ran the test from Mumbai with no bandwidth restriction and got a TTFB of 237ms for the page and 7ms for a static resource.
You restricted the test to 2G, which is very low bandwidth.
So the problem isn't the website, it's the restrictions you placed on your test.
I have a a number of hints
Install monitoring and use it to gather information about your system.
Read your logs to learn more about your system
Learn scientific method, and use it with 1 and 2 above to diagnose faults.
Learn how to write a better question.
What speeds are you actually getting? From what workloads? What kind of disks?
I wouldn't generally recommend using hardware RAID beneath ZFS, but it can be done. One of the things people tend to get badly wrong about striped arrays is that their performance for most workloads trends toward that of a single disk, not toward that of the number of disks in ...
The behavior you describe is often due to an overloaded disk subsystem. The uninterruptible yum update is a good indication that some processes (yum in this case) are in D state (deep sleep), meaning they are waiting for disks to return/accept data.
For additional diagnostic, please provide the output of iostat -x -k 1 while executing some command you find ...
If I understand correctly, you are running linux vm on VMWARE? if so, please check network and disk performance from host machine, can see I/O wait and sy taking long time may be that mean something wrong with host resources allocation to guest machine. RAM looks good, CPU and I/O may be major factor for vm slowness.
@mathias-r-jessen has a great answer though there are details I'd like to add.
In theory threads should be limited by the number of system processors. However, while testing AsyncTcpScan I achieved far better performance by choosing a much larger value for MaxThreads. Thus why that module has a -MaxThreads input parameter. Keep in mind that ...