We are experimenting problems with a WCF-Custom Send Port in BizTalk Server 2009.
Our Send Port is using sapBinding and is very slow. Checking our Performance Counters, the problem is with Outbound Adapter Latency (sec), that sometimes is greater than 5 secs, when the process in SAP is only ms.
How can we check where is exactly the problem? Enabling enablePerformanceCounters property on binding can help with this issue?
UPDATE
I have added the WCF Microsoft.Adapters.SAP Diagnostics and now I can see exactly the invocation time:
I don't understand where the time is lost.
Related
I'm testing an application running on a Raspberry PI via Apache JMeter. Everything works fine but JMeter always return 0 ms latency, no matter how many clients concurrently probe the Raspberry in the time unit.
At beginning I thought this behaviour was due to the short path between the client (my laptop) and the server (the raspberry) as they were on the same subnetwork in my house; then I decided to purposely add a delay on the server application (on the raspberry) before it answer (5 seconds to be precise); the responses were in fact delayed but latency was always 0. I searched on the web and many other users had the same problems but I found nothing that could be useful.
My requests are CoAP messages. I used a Plugin found at https://github.com/starrlingo/jmeter-iot-lib.
I tried several before this but they all gave me the same problem
The plugin you're using does not set latency by calling:
SampleResult#latencyEnd()
See:
https://github.com/emqx/coap-jmeter/blob/master/coap-jmeter/src/main/java/net/xmeter/samplers/CoAPPubSampler.java
https://github.com/emqx/coap-jmeter/blob/master/coap-jmeter/src/main/java/net/xmeter/samplers/CoAPSubSampler.java
Thanks #user7294900 for finding source code of your plugin
I've encountered poor performance in my BizTalk application that uses SOAP/ASMX Receive location web service hosted in IIS on the same sever. This service only invoke one function on Oracle DB (connected via Oracle Driver)
I've done load tests via Soap UI and I stressed DB a little from PL/SQL Profiler in SQL Navigator and it turned out that avg request time = 700ms, avg DB query time = 15ms, avg Orchestration done time = 30ms (via BT Admin Console), so there is an tremendous amount of time wasting by IIS, asmx or SOAP?
I've read this: Configuration Parameters that Affect Adapter Performance and tweaked minFreeThreads , minFreeLocalRequestFreeThreads but nothing really happened.
But as I understand well - there is send port described there and I have problem Receive Location, right?
Also read that article: BizTalk: Performance problems using the SOAP adapter
There is no such key like:
Registry Key:
HKLM\SYSTEM\CurrentControlSet\Services\BTSSvc$BizTalkServerApplication\CLR Hosting
How to achieve Option 2?
Option 2:
Look into process isolation – this would using a different instance of the .NET threadpool executed in a separate address space from the BizTalk NT service.
Guide me please
Go to your receive host properties and change message polling interval to 50ms from default 500ms, that will provide an improved performance. If you're using orchestration on a separate host to process service request and response, do the same on orchestration host but reduce orchestration polling interval. Doing this increase performance for low latency scenario, however it adds overhead on SQL message box. Depending on your volume and need tune this.
Also try upgrading to WCF services
I am using jmeter 2.13 [latest version]. Running a loadtest on https web application with a load of 10000 users. I am using 40 [x250 users/LG] load generators for this. All are 8gb ram & quadcore processors & CentOS operated.
I am getting java.net.socket exception: connection reset issue.
I tried in both options using keep-alive checked & unchecked.
Done all the recommendations need to avoid this issue. Still I am getting the issue. Server is also not showing any issues/logs on reset.
Please help me in understanding the root cause for this issue & how can I avoid this issue.
Also I didn't quite understand the active threads overtime graph? Why the spikes in the graph? Does it mean the thread will connect again after reset? [I have used stop thread on error].
Link given above by Dmitri T is very useful, may fix you problem. If it won't, you may want to consider switching to other HTTP Client implementation. I recently faced a strange issue (probably a bug in client v4), which disappeared afer downgrading client version.
I have a selfhost signalr application, everything is ok but when users become more than 5000, users reconnected rapidly. I know that defalt value of appConcurrentRequestLimit is 5000. and i run this:
cd %windir%\system32\inetsrv
appcmd.exe set config /section:system.webserver/serverRuntime /appConcurrentRequestLimit:100000
but nothing changed. I increased maxConcurrentRequestsPerCPU and requestQueueLimit according to this
but i have got problem yet.
i'm using windows server 2012 and iis 8
You are shooting in the dark here, and you have no data about the actual performance and what's happening. The users could reconnect because of different reasons (server timeouts, regular interval reconnects, server errors). There are countless possibilities.
The correct way to know what's happening and measure performance is to run a Baseline performance load test using the default configuration, and collect the relevant performance counters like current requests, queued requests, current connections, max connections etc.
You should also collect any relevant Error logs on the server that could help you figure out what's happening.
You can find the full list of performance counters you need below:
Memory
.NET CLR Memory# bytes in all Heaps (for w3wp)
ASP.NET
ASP.NET\Requests Current
ASP.NET\Queued
ASP.NET\Rejected
CPU
Processor Information\Processor Time
TCP/IP
TCPv6\Connections Established
TCPv4\Connections Established
Web Service
Web Service\Current Connections
Web Service\Maximum Connections
Threading
.NET CLR LocksAndThreads\ # of current logical Threads
.NET CLR LocksAndThreads\ # of current physical Threads
Once you have your baseline performance results on a graph, then you can modify configuration (e.g. modify the number of concurrent requests like you tried above) and then re-run your test, and collect again the same performance counters.
The performance counter results will speak for themselves, and they will lead you to a solution.
You can generate the load with a tool like Crank:
https://github.com/SignalR/SignalR/tree/dev/src/Microsoft.AspNet.SignalR.Crank
In addition you can also check the SignalR troubleshooting guide:
http://www.asp.net/signalr/overview/testing-and-debugging/troubleshooting
we are having latency issues in one of our network application. Most of the time requests are being handled within 100ms. But sometime it can take up to a few seconds for no apparent reason.
So I hooked up some monitoring tools and looked up what was happening (Wireshark to monitor the network externally through port replication and Process Monitor to see what was happening on the local machine).
I was able to match tcp packets and they usually where within a millisecond of eachother in both logs file. But in one occurence, the last packet of a series was delayed by more then 250ms in Process Monitor compared to wireshark (and the application erratic behavior - due to latency - was being observed).
Since Wireshark was hooked up on another computer I'm quite sure that what was being monitored was accurate : all the packed did reach the network card on time.
As for Process Monitor I'm not totally sure about how it work : when is the network data being registered? Is it when it reach the network card? When it is made available to the application? When the application reads the data?
During these 250ms there were a few other events being registered which let me believe that Process Monitor was recording correctly and that this 250ms delay wasn't "created" by it.
Any help regarding the behavior of Process Monitor, the current method I use to dig down the problem or what you think could be the problem would be much appreciated.
Option 2
Perhaps you're experiencing the infamous 250ms delays that the GC cause from time to time (link). You can accurately measure GC suspensions using a specialized CLR host (link)
Option 1 - was ruled out
Since you are using TCP, I'd suggest that you'll turn on the NoDelay option on your socket just to eliminate the possibility that you're suffering from a clash between Nagle's Algorithm and the Delayed ACKs Algorithm. If you're experiencing "batching" of packets while sometimes a packet is "delayed" for about 200ms, then it just might be the issue.
A more in-depth explanation of this behavior can be found here.