Now you can’t run your application because another process already uses the port. How can you find that process? How to kill it?
Table of Contents
Just a second! 🫷 If you are here, it means that you are a software developer.
So, you know that storage, networking, and domain management have a cost .
If you want to support this blog, please ensure that you have disabled the adblocker for this site. I configured Google AdSense to show as few ADS as possible – I don’t want to bother you with lots of ads, but I still need to add some to pay for the resources for my site.
Thank you for your understanding. – Davide
Sometimes, when trying to run your ASP.NET application, there’s something stopping you.
Have you ever found a message like this?
Failed to bind to address https://127.0.0.1:7261: address already in use.
You can try over and over again, you can also restart the application, but the port still appears to be used by another process.
How can you find the process that is running on a local port? How can you kill it to free up the port and, eventually, be able to run your application?
In this article, we will learn how to find the blocking port in Windows 10 and Windows 11, and then we will learn how to kill that process given its PID.
How to find the process running on a port on Windows 11 using PowerShell
Let’s see how to identify the process that is running on port 7261.
Open a PowerShell and run the netstat command:
NETSTAT is a command that shows info about the active TCP/IP network connections. It accepts several options. In this case, we will use:
-n: Displays addresses and port numbers in numerical form.
-o: Displays the owning process ID associated with each connection.
-a: Displays all connections and listening ports;
-p: Filter for a specific protocol (TCP or UDP)
Notice that the last column lists the PID (Process ID) bound to each connection.
From here, we can use the findstr command to get only the rows with a specific string (the searched port number).
netstat -noa -p TCP | findstr 7261
Now, by looking at the last column, we can identify the Process ID: 19160.
How to kill a process given its PID on Windows or PowerShell
Now that we have the Process ID (PID), we can open the Task Manager, paste the PID value in the topmost textbox, and find the related application.
In our case, it was an instance of Visual Studio running an API application. We can now kill the process by hitting End Task.
If you prefer working with PowerShell, you can find the details of the related process by using the Get-Process command:
Then, you can use the taskkill command by specifying the PID, using the /PID flag, and adding the /F flag to force the killing of the process.
We have killed the process related to the running application. Visual Studio is still working, of course.
Further readings
Hey, what are these fancy colours on the PowerShell?
It’s a customization I added to show the current folder and the info about the associated GIT repository. It’s incredibly useful while developing and navigating the file system with PowerShell.
Can your system withstand heavy loads? You can answer this question by running Load Tests. Maybe, using K6 as a free tool.
Table of Contents
Just a second! 🫷 If you are here, it means that you are a software developer.
So, you know that storage, networking, and domain management have a cost .
If you want to support this blog, please ensure that you have disabled the adblocker for this site. I configured Google AdSense to show as few ADS as possible – I don’t want to bother you with lots of ads, but I still need to add some to pay for the resources for my site.
Thank you for your understanding. – Davide
Understanding how your system reacts to incoming network traffic is crucial to determining whether it’s stable, able to meet the expected SLO, and if the underlying infrastructure and architecture are fine.
How can we simulate many incoming requests? How can we harvest the results of our API calls?
In this article, we will learn how to use K6 to run load tests and display the final result locally in Windows 11.
This article will be the foundation of future content, in which I’ll explore more topics related to load testing, performance tips, and more.
What is Load Testing?
Load testing simulates real-world usage conditions to ensure the software can handle high traffic without compromising performance or user experience.
The importance of load testing lies in its ability to identify bottlenecks and weak points in the system that could lead to slow response times, errors, or crashes when under stress.
By conducting load testing, developers can make necessary optimizations and improvements, ensuring the software is robust, reliable, and scalable. It’s an essential step in delivering a quality product that meets user expectations and maintains business continuity during peak usage times. If you think of it, a system unable to handle the incoming traffic may entirely or partially fail, leading to user dissatisfaction, loss of revenue, and damage to the company’s reputation.
Ideally, you should plan to have automatic load tests in place in your Continuous Delivery pipelines, or, at least, ensure that you run Load tests in your production environment now and then. You then want to compare the test results with the previous ones to ensure that you haven’t introduced bottlenecks in the last releases.
The demo project
For the sake of this article, I created a simple .NET API project: it exposes just one endpoint, /randombook, which returns info about a random book stored in an in-memory Entity Framework DB context.
There are some details that I want to highlight before moving on with the demo.
As you can see, I added a random delay to simulate a random RTT (round-trip time) for accessing the database:
var delayMs = Random.Shared.Next(10, 10000);
// omitawait Task.Delay(delayMs);
I then added a thread-safe counter to keep track of the active operations. I increase the value when the request begins, and decrease it when the request completes. The log message is defined in the lock section to avoid concurrency issues.
Of course, it’s not a perfect solution: it just fits my need for this article.
Install and configure K6 on Windows 11
With K6, you can run the Load Tests by defining the endpoint to call, the number of requests per minute, and some other configurations.
It’s a free tool, and you can install it using Winget:
winget install k6 --source winget
You can ensure that you have installed it correctly by opening a Bash (and not a PowerShell) and executing the following command.
Note: You can actually use PowerShell, but you have to modify some system keys to make K6 recognizable as a command.
The --version prints the version installed and the id of the latest GIT commit belonging to the installed package. For example, you will see k6.exe v0.50.0 (commit/f18209a5e3, go1.21.8, windows/amd64).
Now, we can initialize the tool. Open a Bash and run the following command:
This command generates a script.js file, which you will need to configure in order to set up the Load Testing configurations.
Here’s the scaffolded file (I removed the comments that refer to parts we are not going to cover in this article):
importhttpfrom"k6/http"import { sleep } from"k6"exportconstoptions= {
// A number specifying the number of VUs to run concurrently.
vus:10, // A string specifying the total duration of the test run.
duration:"30s",
}
exportdefaultfunction () {
http.get("https://test.k6.io")
sleep(1)
}
Let’s analyze the main parts:
vus: 10: VUs are the Virtual Users: they simulate the incoming requests that can be executed concurrently.
duration: '30s': this value represents the duration of the whole test run;
http.get('https://test.k6.io');: it’s the main function. We are going to call the specified endpoint and keep track of the responses, metrics, timings, and so on;
sleep(1): it’s the sleep time between each iteration.
To run it, you need to call:
Understanding Virtual Users (VUs) in K6
VUs, Iterations, Sleep time… how do they work together?
I updated the script.js file to clarify how K6 works, and how it affects the API calls.
We are saying “Run the load testing for 30 seconds. I want only ONE execution to exist at a time. After each execution, sleep for 1 second”.
Make sure to run the API project, and then run k6 run script.js.
Let’s see what happens:
K6 starts, and immediately calls the API.
On the API, we can see the first incoming call. The API sleeps for 1 second, and then starts sending other requests.
By having a look at the logs printed from the application, we can see that we had no more than one concurrent request:
From the result screen, we can see that we have run our application for 30 seconds (plus another 30 seconds for graceful-stop) and that the max number of VUs was set to 1.
Here, you can find the same results as plain text, making it easier to follow.
Now, let me run the same script but update the VUs. We are going to run this configuration:
exportconstoptions= {
vus:3,
duration:"30s",
}
The result is similar, but this time we had performed 16 requests instead of 6. That’s because, as you can see, there were up to 3 concurrent users accessing our APIs.
The final duration was still 30 seconds. However, we managed to accept 3x users without having impacts on the performance, and without returning errors.
Customize Load Testing properties
We have just covered the surface of what K6 can do. Of course, there are many resources in the official K6 documentation, so I won’t repeat everything here.
There are some parts, though, that I want to showcase here (so that you can deep dive into the ones you need).
HTTP verbs
In the previous examples, we used the post HTTP method. As you can imagine, there are other methods that you can use.
Each HTTP method has a corresponding Javascript function. For example, we have
get() for the GET method
post() for the POST method
put() for the PUT method
del() for the DELETE method.
Stages
You can create stages to define the different parts of the execution:
With the previous example, I defined three stages:
the first one lasts 30 seconds, and brings the load to 20 VUs;
next, during the next 90 second, the number of VUs decreases to 10;
finally, in the last 20 seconds, it slowly shuts down the remaining calls.
As you can see from the result, the total duration was 2m20s (which corresponds to the sum of the stages), and the max amount of requests was 20 (the number defined in the first stage).
Scenarios
Scenarios allow you to define the details of requests iteration.
We always use a scenario, even if we don’t create one: in fact, we use the default scenario that gives us a predetermined time for the gracefulStop value, set to 30 seconds.
We can define custom scenarios to tweak the different parameters used to define how the test should act.
A scenario is nothing but a JSON element where you define arguments like duration, VUs, and so on.
By defining a scenario, you can also decide to run tests on the same endpoint but using different behaviours: you can create a scenario for a gradual growth of users, one for an immediate peak, and so on.
A glimpse to the final report
Now, we can focus on the meaning of the data returned by the tool.
Let’s use again the image we saw after running the script with the complex stages:
We can see lots of values whose names are mostly self-explaining.
We can see, for example, data_received and data_sent, which tell you the size of the data sent and received.
We have information about the duration and response of HTTP requests (http_req_duration, http_req_sending, http_reqs), as well as information about the several phases of an HTTP connection, like http_req_tls_handshaking.
We finally have information about the configurations set in K6, such as iterations, vus, and vus_max.
You can see the average value, the min and max, and some percentiles for most of the values.
Wrapping up
K6 is a nice tool for getting started with load testing.
You can see more examples in the official documentation. I suggest to take some time and explore all the possibilities provided by K6.
As I said before, this is just the beginning: in future articles, we will use K6 to understand how some technical choices impact the performance of the whole application.
I hope you enjoyed this article! Let’s keep in touch on LinkedIn or Twitter! 🤜🤛