cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

recv() method taking time

gopikrishnanr
Organizer

Hi,

I can see in my purepath tree that there is a method "recv()" of class "System.Net.UnsafeNclNativeMethods+OSSOCK" which is taking most of the time in purepath. I want to find out why this method is slow. I have attached a snap below representing the same :

I can see from method hotspots that it takes mostly when 2 webservices as below are called :

OfflineEApps.svc

EAppBPMServiceRedirect.svc

These 2 services are running on localhost itself and am not understanding why this recv() method hogs when these services are called. Can someone tell me what should I look for?

Thanks,

Gopikrishnan

7 REPLIES 7

Pl. look similiar issue reported here. Also, bad responding Services are problematics irrespective where they are deployed. However, bad responsive services on localhost will surely consume local system resources, further adding to bottleneck.

Hi Rajesh,

I tried but am not able to pinpoint the exact issue. Please help

martin_chochke1
Advisor

I would suggest placing a sensor on the method to get more insight and meaningful metrics regarding that method, it'll help with your investigation.

I think Auto-sensor is giving hint about slowness (hotspot). Also the recv() is lower level API, should be skipped from explicit sensor. Regards, Rajesh

gopikrishnanr
Organizer

Hi Martin,

Sensor cannot be placed on native methods and hence that possibility cannot happen.

You should put whole focus on optimizing the poor response from the back end services. To start with, raise this concern with the application team for troubleshooting the high response time. The issues may be related to Code level or configuration level. That you have to identify. Start tracking the Load vs Response time for each service. Once you are sure at what load services start performing poor then you should proceed with the further investigation. Regards, Rajesh.

Can you tell me which configuration to check for this because still we are stuck at the same.

Regards,

Gopikrishnan