What are the elements inside DotNet?

In this article, we are going to see major elements which are present inside Dot Net that are important for Performance Investigation. This post only covers dotnet overview as platform. I will post another post for run time internals.

First of all, what is dotnet?. Is it a framework? or a run time? or a platform or a system? We will see different definitions associated with the supporting logic in various places. Actually, (in my opinion), it is a software development platform combined with different systems.

To think simply, Dotnet is a development platform for windows environments*.

Its very simple. Now, Let see, what is inside Dotnet. To have clarity, let’s know some history of Dotnet. The successor of dotnet was, VB. VB was a wonderful and easy platform to develop windows application along with COM(Component Object Model). After evolution of 32bit OS and now in 64 bit OS, it was hard to manage legacy support for old software and driver for devices. Microsoft came up with evolutionary idea to have a platform having multiple language support (spatially they need some language for OOP support which can be competent to Java) and generic compiled code which can be run-able the same way for all language generated(compiled) code. So, like as Java, Microsoft Introduce Intermediate Language Code. (IL, similar to Class files in Java). So, the We see the dot net has 2 major component.

A. IL code generator (Like as JDK)

B. IL code runner (CLR, Like as JRE)

A. What is IL code generator? This is a full set of language , its compiler, its IL Code generator , targeted for one thing. Creating your code into run-able intermediate language. Which is called IL code. Let’s see, what are items inside of this.

1. Different languages, script like c++, C#, J#, VB etc.

2. Compilers respect to each language , like c++ compiler, c# compiler, J# compiler, VB compiler.

3. CTS : Common type system which actually has all of the type definitions used for different languages supported by dotnet. Like as common type for all language. Simple Example : Int32 is a common type which is int in c#, integer in VB. So, it is easily understandable, CTS is followed by all language compilers. And, all CTS items must have direct run-able capability to CLR(IL code runner)

4.  CLS :  Common language Specification : This is common agreement between all languages of Dotnet. This is very important due to , framework or class designers will follow the specification to make a single IL code accessible from all language. In summary, CLS has the specification which should be common for all language. So, definitely, it is subset of CTS. I found this nice picture from internet defining CTS/CLS nicely.

5. Base Classes : Like JDK, Dotnet also have some Base class libraries which helps to build application. These are called Base Classes. This is provided by Microsoft commonly used for all languages (as it follows CLS). Example : ADO.Net, I/O, Diagnostics, Environment controlling libraries etc. From 3.5, Microsoft add some smart libraries named as Layer Cake.

6. Foundations : To make development attractive and targeted for specific user problems, Dotnet brings different type of application development as suit which contains different base classes and associated runtime system. Like, for web , ASP.net. For mobile, win mobile platform, for desktop, win forms , WPF etc.

So, after those components are being in interaction, dot net IL compilers generate IL code.
When IL code generated, it generated with Dotnet assembly, which contains
->IL Code
->Resource Files
->Type Meta Data
->Code Meta data or assembly Manifest
I will provide separate post for DotNet assembly only.
B. IL Code runner : Which is named as CLR, common language runtime. It is similar concept as JRE. The main responsibility of CLR is to run your code produced IL in optimized way. To run IL, CLR has major 4 components.
1. GC(Garbage Collector)
2. CAS(Code Access Security)
3. CV(code Verification)
4. Translator(From IL to Native)

[Jit : Just In time Compiler , is subset of CLR which compiles and executes the code
Language Code > Language  Compiler > IL > .NET Runtime > JIT Compiler > Machine code > Execution ]

This is part is very important as performance engineer where we have to provide evidence of performance issues caused by code. I will provide separate blog posts on each of those.

So, finally, the image has become this.
Image from Internet :
Note :
* -> Now a days, with mono project and CLR being open sourced, it is possible to run certain version of DotNet over Linux. 

One of the major source : This link

How many users jmeter can support?

In this article we are going to learn to calculate How many users a jmeter instance can support?

This is very important as, after creating scenario and test cases, we need to run using Jmeter. Before going deeper into the conversation, we need to consider following facts , assumptions and steps to know the number.

-> x86 operating system and x86 both has memory expansion limitation upto 4gb where 3.2gb(+/-), so to have optimal output from Jmeter, you need to use x64 for both Operating system and Java edition.

-> Jmeter is Java tool. It run with JVM. To obtain maximum capability, we need to provide maximum resources to Jmeter during execution. In jmeter, bin directory, we get jmeter.bat/sh. Open this file with text editor.(windows ->.bat, Linux->.sh). First, we need to increase heap size
HEAP=-Xms1024m -Xmx8192m
It means, heap size minimum 1GB, maximum up to 8GB. I ran this to my 16GB PC. Configure following you own PC configuration.
Keep in mind, OS also need some amount of memory, so don't allocate all of you physical RAM.

Then, add memory allocation rate .
NEW=-XX:NewSize=128m -XX:MaxNewSize=512m

This means, memory will be increased in this rate. You should be careful, because, if your load generation is very high at the beginning, this might need to increase. I used to run gradually load, so, max new size 512MB is okay. But , if you are testing for large application with many threads , you need this new size to be bigger.
Keep in mind, the bigger size will fragment you heap space inside JVM, so, GC need to work harder to clean up.

-> How Jmeter executes? During test execution, Jmeter will manage data all over RAM. And, use virtual storage as buffer. So, All of you user threads will be in memory which are running concurrently. In summery, estimate your concurrent number user/thread (active threads) in load scenario. Those will be in memory.

-> Jmeter is Java GUI application. It also has non GUI edition which is very resource intensive(CPU/RAM). If we run Jmeter in non GUI mode , it will consume less resource and we can run more thread.

-> As, JVM manages application with some Demon thread inside JVM, we need to consider some resources for those items. Those are kind of managers of application as part of JVM. So, technically, Jmeter cannot get full memory that we allocated as heap space , a significant amount of memory can be deducted in JRE. It is not exact, usually, I deduct 1GB or more during large request execution.

So, after following all of those lets measure. Initial steps will be.

Step 1:  Calculate total size of the requests inside test cases. (use View Results in Table Listener). Usually, total time of single user is ignored due to JVM GC collection time cannot be measured, so , we are assuming no GC will be necessary for execution.

Step 2: Now, Consider the Network speed. Measure how much bandwidth you need to run 1 user with total request. Your PC resource may support all of those users, but, those requests might not get bandwidth to execute. (use View Results in Table Listener). We just need to validate the maximum bandwidth of PC/test environment should be higher than total concurrent users(target)

Step 3: The total number of concurrent user = (total allocable memory)/(Size of the all requests)

Example : Let's assume we have Amazon C4.xLarge instance
(Ubuntu server+Java8x64+4vCpu+7.5Gb+750MBps)
and our test case has 5 http request total consumes 4.5MB data for a single user/thread.

So, if we set Jmeter up to 6GB(Xmx6144m).
Then we should be able to run scenario where the concurrent user count = (6144-1024)/4.5 = 1137.7 , consider as 1100 concurrent user.

Note : This is very typical calculation assuming best possible scenarios like
-No Listeners are included in Jmeter script
-No monitoring inside running jmeter servers
-No network overhead/barriers.
-Jmeter scripts are optimized.
-JVM demon process are allocated with 1GB Ram, if you run less number of concurrent users with lighter requests, it might be less than 1GB.

This is from my test execution experience, please add yours.

How to design load scenario for performance testing?

In this article we are going learn about Load Profile for performance testing. That means how to identify and design load test scenario for performance testing based on requirement. I am adding my experiences, feel free to comment your experiences too.

Before starting this article, I would recommend you to have clear idea on Performance Goal, Requirement. This will help you to understand your product.

This process is very simple but very logical.
Steps 1 : Understand your product and users : Get to know your product in more details from business requirements or any available requirement document (SRS,BRS etc). We need to know mainly
a. High load (Peak users, This is stress condition, application should perform with expected behavior in this situation)
b. Average load(This is Base line standards, application should pass minimum this standard.)
c. maximum user application support. (spike users, application should be able tolerate sudden user increments, may be with certain specific behaviors like spatial message, wait screen user notification/feedback but it should not be broken)

Step 2. Understand Business goal and target : Try to find out why those requirements(from step 1) are there. What are the business justification for that? And design scenario accordingly.
Example, if you get requirement " We need 100k concurrent User access" then you need to find out
a. Why this kind of requirement was made?
b. What achievement will be done with this?
c. what are the situation Business is expecting,
d. What is the target for business/revenue.

Step 3. Understand the architecture : Before design scenario, you should be careful on understanding the architecture. spatially
a. How it was designed? Overall component diagram
b. How modules interacts to each other? Interaction diagram
c. What are possible bottleneck areas you may find from previous experiences or from community?(have a Google search on those) 
d. Does those areas related to selected scenario? If yes, include those checking inside test script

Step 4.Understand your tools : This is very tricky & hard.And it might take long time. You need to care about 
a. How your tool works?
b. How tool generate and manage load
c. How your project planned to run tests(Local execution/Remote execution/ CI execution etc).
d. What are the optimal setting and configuration of the tool that is best for your application.
e. How to tune tool and test cases for your application performance context(to be the best fit)

Now, let's make some scenario based on web application. I will try to make some scenario based on performance target.
1. Target : High page availability : This is very typical case for web application. Main target , page available all the time and no error/server outage. To, fulfill this, the scenario should be ..
Total User/Thread = Total number of request in whole scenario
Ramp up = This is value is tricky,
for a gradually load generation it will be Total Single Execution period /Total User( User will be created in static incremental rate)
for a spike load generation, it will be less than previous measurement. The less you assign , the more user will be created in small period of time.
Some time, test tools used to iterate, usually this test have 1 iteration unless you need to run it for a long time.
->High availability checking(http 200 validation always)

2. Target : High user activity : This is very typical social media or forum web application behavior where user used to have long activity, not necessarily large number of data but long time session.
So, for these kind of requirement, your Total User might be limited.
So, ramp up will be as less as possible but test execution will be longer. Usually 1 hour to 4/5 hours. This can be achieved by time driven tests or multiple iteration. 

3.Target  : Large data exchange : Usually Banks or financial data transactions have these kind of requirement where a large amount of data exchanged during an user activity. In this case, number of user might not factor that much but data validation as well as data redundancy, integrity is important. These type of test includes long time execution with multiple iterations.
So, ramp up should be maximum allowed for load generators
Total execution usually start with one hour, some cases I found up to 48 hours. This time length can be achieve by multiple iteration. Now a days tools have this built in inside tool for time driven tests.
Note : Usually , APM tools also run while doing the test. You need to know application architecture carefully to make these type of scenario to validate error conditions.

4.Target : Complex/Dynamic pages activity: This is very tricky scenarios, because based application dynamic condition, pages changes behavior, like based on time, data, user credential. Usually, stress conditions are applied in such WebPages. So, there should be
->Less Ramp Up time
->Max/Spike Users condition
->Multiple iteration with different dynamic conditions which changes application behaviors. I suggest , keep multiple scenario running in single test session. So that, those pages stress can be validate.

5.Target : Long time support/Capacity testing : This is very common case when it is needed for validating memory/IO/ CPU capacity. Usually, capacity will be stressed out via.
-> short ramp up with certain spike users( to validate sudden resources usages)
-> Long time execution , 2/4 hours with High user load condition
-> Long time execution , 7-30 days with Average/High user load condition.
This type of test must need continuous monitoring some time with application profilers.

In all cases, You need to care about
1. You full load scenario should validate High Load & Max User count.
2. System errors conditions.
3. High data usages conditions.
4. If you have SLA/Requirement for concurrency/throughput/HPS etc, they you need to apply inside transaction/step

Note : 
Iteration pacing is the delay for each user full scenario completion.
Ramp Up is the Time we allow load generators to create users/thread