Here's another vote for JMeter.
JMeter is an open-source load testing tool, written in Java. It's capable of testing a number of different server types (for example, web, web services, database, just about anything that uses requests basically).
It does however have a steep learning curve once you start getting to complicated tests, but it's well worth it. You can get up and running very quickly, and depending on what sort of stress-testing you want to do, that might be fine.
Pros:
- Open-Source/Free tool from the Apache project (helps with buy-in)
- Easy to get started with, and easy to use once you grasp the core concepts. (Ie, how to create a request, how to create an assertion, how to work with variables etc).
- Very scalable. I've run tests with 11 machines generating load on the server to the tune of almost a million hits/hour. It was much easier to setup than I was expecting.
- Has an active community and good resources to help you get up and running. Read the tutorials first and play with it for a while.
Cons:
- The UI is written in Swing. (ugh!)
- JMeter works by parsing the response text returned by the server. So if you're looking to validate any sort of javascript behaviours, you're out of luck.
- Learning curve is steep for non-programmers. If you're familiar with regular expressions, you're already ahead of the game.
- There are large numbers of (insert expletive) idiots in the support forum asking stupid questions that could be easily solved if they'd give the documentation even a cursory glance. ('How do I use JMeter to stress-test my Windows GUI' shows up quite frequently).
- Reporting 'out of the box' leaves much to be desired, particularly for larger tests. In the test I mentioned above, I ended up having to write a quick console app to do some of the 'xml-logfile' to 'html' conversions. That was a few years ago though, so it's probable that this would no longer be required.
I think you are attacking it from the wrong angle by trying to encode all posted data.
Note that a "<" could also come from other outside sources, like a database field, a configuration, a file, a feed and so on.
Furthermore, "<" is not inherently dangerous. It's only dangerous in a specific context: when writing strings that haven't been encoded to HTML output (because of XSS).
In other contexts different sub-strings are dangerous, for example, if you write an user-provided URL into a link, the sub-string "javascript:" may be dangerous. The single quote character on the other hand is dangerous when interpolating strings in SQL queries, but perfectly safe if it is a part of a name submitted from a form or read from a database field.
The bottom line is: you can't filter random input for dangerous characters, because any character may be dangerous under the right circumstances. You should encode at the point where some specific characters may become dangerous because they cross into a different sub-language where they have special meaning. When you write a string to HTML, you should encode characters that have special meaning in HTML, using Server.HtmlEncode. If you pass a string to a dynamic SQL statement, you should encode different characters (or better, let the framework do it for you by using prepared statements or the like)..
When you are sure you HTML-encode everywhere you pass strings to HTML, then set ValidateRequest="false" in the <%@ Page ... %> directive in your .aspx file(s).
In .NET 4 you may need to do a little more. Sometimes it's necessary to also add <httpRuntime requestValidationMode="2.0" /> to web.config (reference).
Best Solution
Here is the free tool for the stress testing in asp.net application.
https://docs.microsoft.com/en-us/archive/blogs/alikl/stress-test-asp-net-web-application-with-free-wcat-tool
Another is called asp.net performance engineering which will tell how we can stress application.
https://docs.microsoft.com/en-us/archive/blogs/alikl/asp-net-performance-engineering-stress-test-your-architecture-design-and-code
Also go through the following post:
Best way to stress test a website
From my experience before moving to the production environment please take of following things.
set debug=false into the web.config
set trace enabled=false into the web.config
Always use precompiled version of your code.
Compile your project into the release mode.
Publish your code if you are using asp.net 2.0 or higher version
User caching api as much as possible.
Decrease your html kb.
remove blank spaces from the asp.net html code.
Use stylesheet as external .css file
USE IIS Compression if poosible.
Put your javascript file in .js files
Use Server.Transfer instead of Response.redirect
Use Inproc Session State if possible.
Use Viewstate efficiently- Use controlstate instead of viewstate which is newer feature in asp.net 2.0
Avoid giving big name to controls it will increase your html kb.
Use Div instead of tables it will decrease your size.
Do IIS Performance tuning as per your requirement
Here is the good link that teaches us good way of deployment in production environment.
http://www.vbdotnetheaven.com/UploadFile/dsdaf/111222006014732AM/1.aspx