Tracking Outbound Connections

Detecting outbound connection queuing for ASP.NET website

The problem you are describinng touches many areas of diagnostics and I suppose there is no one simple tool that will allow you to say whether you suffer contention or not. From your description it looks like your depleting either connection or thread pools. This usually involves thread locking. Apart from the HttpWebRequest Average Queue Time performance counter pointed by @Simon Mourier (remember to set performancecounters="enabled" in your config file) there are few more to monitor. I would start with custom performance counters that will monitor thread pool usage in your ASP.NET application - unfortunately they are not included into framework counters but they are fairly simple to implement as shown here. Additionally I wrote a simple powershell script that will group for you thread states in your application. You may get it from here. It resembles a bit top command in Linux and will show you thread states or thread wait reasons for your processes. Have a look at 2 applications (both named Program.exe) screenshots:

one suffering from contention

> .\ThreadsTop.ps1 -ThreadStates -ProcMask Program

Threads states / process

Process Name Initialized Ready Running Standby Terminated Waiting Transition Unknown
------------ ----------- ----- ------- ------- ---------- ------- ---------- -------
Program 0 0 0 0 0 22 0 0

and the number of waiting threads constantly growing

> .\ThreadsTop.ps1 -ThreadWaitReasons -ProcMask Program

Legend:
0 - Waiting for a component of the Windows NT Executive| 1 - Waiting for a page to be freed
2 - Waiting for a page to be mapped or copied | 3 - Waiting for space to be allocated in the paged or nonpag
ed pool
4 - Waiting for an Execution Delay to be resolved | 5 - Suspended
6 - Waiting for a user request | 7 - Waiting for a component of the Windows NT Executive
8 - Waiting for a page to be freed | 9 - Waiting for a page to be mapped or copied
10 - Waiting for space to be allocated in the paged or nonpaged pool| 11 - Waiting for an Execution Delay to be resolve
d
12 - Suspended | 13 - Waiting for a user request
14 - Waiting for an event pair high | 15 - Waiting for an event pair low
16 - Waiting for an LPC Receive notice | 17 - Waiting for an LPC Reply notice
18 - Waiting for virtual memory to be allocated | 19 - Waiting for a page to be written to disk

Process Name 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
------------ - - - - - - - - - - -- -- -- -- -- -- -- -- -- --
Program 1 0 0 0 0 0 34 0 0 0 0 0 0 0 0 3 0 0 0 0

and other running normally:

> .\ThreadsTop.ps1 -ThreadStates -ProcMask Program

Threads states / process

Process Name Initialized Ready Running Standby Terminated Waiting Transition Unknown
------------ ----------- ----- ------- ------- ---------- ------- ---------- -------
Program 0 1 6 0 0 20 0 0

the number of waiting threads does not gets higher than 24.

> .\ThreadsTop.ps1 -ThreadWaitReasons -ProcMask Program

Legend:
0 - Waiting for a component of the Windows NT Executive| 1 - Waiting for a page to be freed
2 - Waiting for a page to be mapped or copied | 3 - Waiting for space to be allocated in the paged or nonpag
ed pool
4 - Waiting for an Execution Delay to be resolved | 5 - Suspended
6 - Waiting for a user request | 7 - Waiting for a component of the Windows NT Executive
8 - Waiting for a page to be freed | 9 - Waiting for a page to be mapped or copied
10 - Waiting for space to be allocated in the paged or nonpaged pool| 11 - Waiting for an Execution Delay to be resolve
d
12 - Suspended | 13 - Waiting for a user request
14 - Waiting for an event pair high | 15 - Waiting for an event pair low
16 - Waiting for an LPC Receive notice | 17 - Waiting for an LPC Reply notice
18 - Waiting for virtual memory to be allocated | 19 - Waiting for a page to be written to disk

Process Name 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
------------ - - - - - - - - - - -- -- -- -- -- -- -- -- -- --
Program 1 0 0 0 0 0 18 0 0 0 0 0 0 0 0 6 0 0 0 0

Of course the number of threads will be much higher in your case but you should be able to observe some tendency in threads behavior in "calm times" and waiting queue peaks when you suffer from contention.

You may freely modify my script so it will dump this data somewhere else than console (like database). Finally I would recommend running profiler such as Concurrency Visualizer that will give you some more insight into threads behavior in your application. Enabling system.net trace sources might also help although the number of events might be overwhelming so try to tune it accordingly.

Tracking outgoing links with Javascript and PHP

To get the best results you should change two things in your approach

  1. Use onmousedown instead of click - this way you get a few extra milliseconds to complete the tracking request, otherwise the browser might not start the connection to your tracker at all as it is already navigating away from the original page. The downside is that you might get some false-positive counts, since the clicking user might not finish the click (eg. keeps the mousebutton down and moves the cursor away from the link) but overall it's a sacrifice you should be willing to make - considering the better quality of tracking.
  2. Instead of an Ajax call ($.post('...')) use an image pre-fetcher (new Image().src='...'). The fact that the tracker is not an image is not relevant in this case because you don't want to use the resulting "image" anyway, you just want to make a request to the server. Ajax call is a two way connection so it takes a bit more time and might fail if the browser is already navigating away but the image pre-fetcher just sends the request to the server and it doesn't really matter if you get something back or not.

So the solution would be something like this:

<script>
$(document).ready(function() {
$("a").mousedown(function (){
new Image().src= "http://www.example.com/trackol.php?result=click";
});
});
</script>

<a href="http://www.google.com">out</a>

How to track clicks on outbound links

Here's what I'm using, which has been working for me. I'm using jQuery to add the onclick handler to any link with a class of "referral", but I'd expect adding it directly in the HTML to work as well.

  $(function() {
$('.referral').click(function() {
_gaq.push(['_trackEvent', 'Referral', 'Click', this.href]);
setTimeout('document.location = "' + this.href + '"', 100);
return false;
});
});

edit: I believe your syntax for invoking a tracker by name is wrong. Since you aren't using a named tracker when you set up tracking at page load, you shouldn't try to name it later either. See the documentation for _gaq.push.

More precisely:

  1. The var myTracker declaration is unused, so you can just delete that line. Variables declared within the scope of recordOutboundLink aren't visible when other functions, such as _gaq.push, are running, so it can't be relevant.
  2. You should simply use '_trackEvent' instead of 'myTracker._trackEvent'.

How to get process/PID responsible for creating outbound connection request (linux) (command line)

Using mbax's & Dude Boy input you could do this:

#!/bin/bash

while true
do
PID=$(netstat -nputw | grep 185.191.32.198)
if [ $? -ne 0 ]; then
:
else
ps -ajxf
echo "PID: ${PID}"
exit
fi
done

As a oneliner:

while true; do PID=$(netstat -nputw | grep 185.191.32.198); if [ $? -ne 0 ]; then :; else ps -ajxf; echo "PID: ${PID}"; break; fi; done

Edit: The original while timer 0.1 did not detect every attempt I tested, 0.01 did.

Edit 2: Using true uses up to 2% CPU, worth it when hunting ;)

Avoiding double inbound/outbound connection between bittorrent peers

Or do clients generally just close one of the two connections randomly?

More or less that, although with some biases such as preferring the longer-lived connection to stay alive or with some randomized delay to prevent simultaneous close attempts.

The situation that two clients initiate a connection to each other at the same time is not that common anyway, most of the time things will be different enough between peers that one will be clearly arrive first and then the other side will know about it and avoid the reverse attempt.

Sidenote: One shouldn't trust the peer ID too much. It's useful, but an adversarial client could intentionally pick the ID of another one or randomize it on every connection.



Related Topics



Leave a reply



Submit