Where and what should we check if you are getting poor response time but rest of the other performance parameters are performing well?

Poor Response time but rest parameters are performing fine

You need to focus on time measurements and to drill down the stack. But where should you start? Unfortunately, the test report does not highlight a bottleneck. 
An effective tool to troubleshoot performance of a transaction issued by a single user is a waterfall diagram thanks to its clear visualization. It displays on which requests most of the response time was spent. 
Here's the approach that we use to find bottlenecks by using waterfall diagrams in load tests. Log the entire test traffic. After the test is complete, select a single user / iteration and display its waterfall diagram. It will show bottleneck requests for this VU during a selected iteration with certain load level.

The instrumentation for this approach is built into our load testing tool, but you can generate a waterfall diagrams without it by using Fiddler, a free web debugging proxy as follows: 
1. Install Fiddler on the LR machine 
2. In LR configure proxy on port 8888. Make sure that LR traffic is captured by Fiddler 
3. In LR add a script that inserts a request header "Fiddler-Capture" for one selected VU and iteration (use web_add_header function) 
4. In Fiddler Main Menu > Rules, click Customize Rules. A script editor will open. Find OnBeforeRequest function and add the following script: 
if (oSession.oRequest.headers.Exists("Fiddler-Capture")) 
{ 
//--- Remove the header 
oSession.oRequest.headers.Remove("Fiddler-Capture"); 
} 
else 
{ 
//---- Hide the request from the grid 
oSession.oFlags[Utils.HIDE_FLAG] = "yes"; 
}

5. Run the test. Fiddler will pass-through the entire traffic and will capture sessions with Fiddler-Capture header in the session grid. 
6. Once the test is complete, select the captured sessions in the grid and click Timeline tab that will display a waterfall diagram like this one -http://support.stresstimulus.com/display/doc37/Waterfall+Chart

To select a different VU/iteration, you need to change them in the LR script and rerun the test (our tool does not have this limitation as it stored the entire test log in the queryable database). 
After looking at the diagrams you will know what actions caused the slowness.

Firebug and HTTP Watch

There are many tools that you can use to generate a waterfall diagram of a page. Both, HTTP Watch and Firebug have it. Such tools are used to diagnose performance of a page accessed by one user. If your transaction is slow when used by a single user, then such tools are extremely helpful to pinpoint a bottleneck even without load testing. 
If however your transaction has a scalability problem and slowness is exposed only under load, then using such tools can be tricky. 

The 1st challenge is that you need to generate a waterfall diagram at a time when your server is under load. Because Firebug has no synchronization with LR, you would need to figure out yourself the load level at the moment when the waterfall diagram was created. 
The 2nd challenge is that most of such tools capable of generating a page waterfall diagram, which can be an obstacle if your transaction comprises multiple pages. 
The 3rd challenge is to make sure that the Firebug user operates in a similar environment as VUs in LR, otherwise you will compare apples and oranges. 

We addressed these challenges in our tool. Using Fiddler will also allows to generate a waterfall diagram for a VU participated in the load test so you will compare apples to apples. 
Hope this will help and good luck with your performance troubleshooting.