How to improve the search result:-

1. Do not refresh the left filters (Location, Title, and Company etc), sponsors jobs and
sponsors ads while navigating through paging.

2. use of AJAX, update panel on search page, parital submitting the page

3. Check “Page.IsPostBack”. To avoid repetition code execution, all the code which is to be
executed only once on page put into ispostback.

Make sure you don't execute code needlessly. Use Page.ISPostBack property to ensure
that you only perform page initialization logic when a page is first time loaded and not in
response to client postbacks

4. Set debug=false under compilation as follows:

<compilation default Language="c#" debug="false">
When you create the application, by default this attribute is set to "true" which is very
useful while developing. However, when you are deploying your application, always set it
to "false".
How it affects performance:
Setting it to "true" requires the pdb information to be inserted into the file and this results
in a comparatively larger file and hence processing will be slow.
Solution:
Therefore, always set debug="false" before deployment

5. Use Server.Transfer instead of Response.Redirect

Response.Redirect () method simply tells the browser to visit another page.
How it affects performance:
Redirects are also very chatty. They should only be used when you are transferring
people to another physical web server.
Solution:
For any transfers within your server, use .transfer! You will save a lot of needless HTTP
requests. Instead of telling the browser to redirect, it simply changes the "focus" on the
Web server and transfers the request. This means you don't get quite as many HTTP
requests coming through, which therefore eases the pressure on your Web server and
makes your applications run faster.

Tradeoffs:
? ".transfer" process can work on only those sites running on the server. Only
Response.Redirect can do that.
? Server.Transfer maintains the original URL in the browser. This can really help
streamline data entry techniques, although it may make for confusion when debugging
5. A) To reduce CLR Exceptions count, Use Response.Redirect (".aspx", false) instead of
response.redirect (".aspx").

6. Always check Page.IsValid when using Validator Controls

Always make sure you check Page.IsValid before processing your forms when using
Validator Controls.

7. Use Foreach loop instead of For loop for String Iteration.

 Foreach is far more readable, and in the future it will become as fast as a For loop for special
cases like strings. Unless string manipulation is a real performance hog for you, the slightly
messier code may not be worth it.

8. Turn off Tracing unless until required. (by default it's off, use on the pages where it's
required)

Tracing is one of the wonderful features which enable us to track the application's trace and the
sequences. However, again it is useful only for developers and you can set this to "false" unless
you require to monitor the trace logging.
How it affects performance:
Enabling tracing adds performance overhead and might expose private information, so it should
be enabled only while an application is being actively analyzed.
Solution:
When not needed, tracing can be turned off using
<trace enabled="false" requestLimit=”10” pageoutput=”false” traceMode=”SortByTime”
localOnly=”true”>

9. Turn off Session State, if not required.

<sessionstate timeout="20" cookieless="false" mode="Off"

stateconnectionstring="tcpip=127.0.0.1:42424" sqlconnectionstring="data
source=127.0.0.1;Trusted_Connection=no">

One extremely powerful feature of ASP.NET is its ability to store session state for users, such as
a shopping cart on an e-commerce site or a browser history.
How it affects performance:
Since ASP.NET Manages session state by default, you pay the cost in memory even if you don't
use it. I.e. whether you store your data in in-process or on state server or in a Sql Database,
session state requires memory and it's also time consuming when you store or retrieve data from
it.
Solution:
You may not require session state when your pages are static or when you do not need to store
information captured in the page.
In such cases where you need not use session state, disable it on your web form using the
directive,
<@%Page EnableSessionState="false"%>
In case you use the session state only to retrieve data from it and not to update it, make the
session state read only by using the directive,
<@%Page EnableSessionState ="ReadOnly"%>

10. Disable ViewState when not required.

EnableViewState="false"

View state is a fancy name for ASP.NET storing some state data in a hidden input field inside the
generated page. When the page is posted back to the server, the server can parse, validate, and
apply this view state data back to the page's tree of controls.
View state is a very powerful capability since it allows state to be persisted with the client and it
requires no cookies or server memory to save this state. Many ASP.NET server controls use view
state to persist settings made during interactions with elements on the page, for example, saving
the current page that is being displayed when paging through data.
How it affects performance:
? There are a number of drawbacks to the use of view state, however.
? It increases the total payload of the page both when served and when requested. There is also
an additional overhead incurred when serializing or deserializing view state data that is posted
back to the server.
? View state increases the memory allocations on the server. Several server controls, the most
well known of which is the DataGrid, tend to make excessive use of view state, even in cases
where it is not needed.
Solution:
Pages that do not have any server postback events can have the view state turned off.
The default behavior of the ViewState property is enabled, but if you don't need it, you can turn it
off at the control or page level. Within a control, simply set the EnableViewState property to false,
or set it globally within the page using this setting:
<%@ Page EnableViewState="false" %>
If you turn view state off for a page or control, make sure you thoroughly test your pages to verify
that they continue to function correctly.

11. Avoid frequent round trips to the Database.

13. Enabling buffering will improve the performance, like

<% response.buffer=true %>

Then use:

<% response.flush=true %>

14. Avoid Inline JavaScript and CSS

Place StyleSheets into the Header
Web developers who care about performance want browser to load whatever content it has as
soon as possible. This fact is especially important for pages with a lot of content and for users
with slow Internet connections. When the browser loads the page progressively the header, the
logo, the navigation components serve as visual feedback for the user.
When we place style sheets near the bottom part of the html, most browsers stop rendering to
avoid redrawing elements of the page if their styles change thus decreasing the performance of
the page. So, always place StyleSheets into the Header

15. Reduce cookie size

16. Use strString=string.Empty instead of strString="" . [And perhaps instead of

strString=null also (?)]

17. Use Cache appropriately

How it improves performance:

ASP.NET allows you to cache entire pages, fragment of pages or controls. You can cache also
variable data by specifying the parameters that the data depends. By using caching you help
ASP.NET engine to return data for repeated request for the same page much faster.
When and Why Use Caching:
A Proper use and fine tune of caching approach of caching will result on better performance and
scalability of your site. However improper use of caching will actually slow down and consume
lots of your server performance and memory usage.
Good candidate to use caching is if you have infrequent chance of data or static content of web
page.
i. Page output caching:

<%@ OutputCache Duration="3600" VaryByParam="none" %>

ii. Page fragment caching:

Write a Page output caching code into each User Control

iii. Data caching:

<script language="C#" runat="server">

Protected void Page_Load (Object src, EventArgs e) {

DataView dv = (DataView) Cache. Get ("EmployeesDataView");

If (dv == null) { // wasn't thereSqlConnection conn =

new SqlConnection ("server=localhost;uid=sa;pwd=;database=Test");

SqlDataAdapter da =new SqlDataAdapter ("select * from Employees", conn);

Dataset ds = new DataSet();da.Fill(ds, "Employees");

dv = ds.Tables["Employees"].DefaultView;

Cache.Insert ("EmployeesDataView", dv);conn.Close();}

Else

Response.Write ("<h2>Loaded employees from data cache! </h2>");

lb1.DataSource = dv;

lb1.DataTextField = "Name";

lb1.DataValueField = "Age";

DataBind () ;}

</script>

18. Make your page files as light as possible. That is try to avoid unnecessary markups, e.g. use
div elements instead of tables.

19. Write static messages in div and make it visible when necessary. This is faster than letting
server set Text property of your label or div.

20. Retrieve data from database at once, if possible. Don't add up to database trip as far as
possible. For this, combine the datafields from different tables and select them.
21. Use the String builder to concatenate string
How it affects performance:
String is Evil when you want to append and concatenate text to your string. All the activities you
do to the string are stored in the memory as separate references and it must be avoided as much
as possible.
i.e. When a string is modified, the run time will create a new string and return it, leaving the
original to be garbage collected. Most of the time this is a fast and simple way to do it, but when a
string is being modified repeatedly it begins to be a burden on performance: all of those
allocations eventually get expensive.
Solution:
Use String Builder when ever string concatenation is needed so that it only stores the value in the
original string and no additional reference is created.

22. Use Finally Method to kill resources

?The finally method gets executed independent of the outcome of the Block.
?Always use the finally block to kill resources like closing database connection, closing files and
other resources such that they get executed independent of whether the code worked in Try or
went to Catch.

23. Avoid unnecessary round trips to the server

How it affects performance:
Round trips significantly affect performance. They are subject to network latency and to
downstream server latency. Many data-driven Web sites heavily access the database for every
user request. While connection pooling helps, the increased network traffic and processing load
on the database server can adversely affect performance.
Solution:
? Keep round trips to an absolute minimum
? Implement Ajax UI whenever possible. The idea is to avoid full page refresh and only update
the portion of the page that needs to be changed

24. Include Return Statements with in the Function/Method

How it improves performance
Explicitly using return allows the JIT to perform slightly more optimizations. Without a return
statement, each function/method is given several local variables on stack to transparently support
returning values without the keyword. Keeping these around makes it harder for the JIT to
optimize, and can impact the performance of your code. Look through your functions/methods
and insert return as needed. It doesn't change the semantics of the code at all, and it can help
you get more speed from your application.

25. Avoid Unnecessary Indirection

How it affects performance:
When you use byRef, you pass pointers instead of the actual object.
Many times this makes sense (side-effecting functions, for example), but you don't always need it.
Passing pointers results in more indirection, which is slower than accessing a value that is on the
stack.
Solution:
When you don't need to go through the heap, it is best to avoid it there by avoiding indirection.

26. Minimize the number of web server controls

How it affects performance:
The use of web server controls increases the response time of your application because they
need time to be processed on the server side before they are rendered on the client side.
Solution:
One way to minimize the number of web server controls is to taking into consideration, the usage
of HTML elements where they are suited, for example if you want to display static text.

27. Avoid using unmanaged code

How it affects performance:
Calls to unmanaged code are a costly marshaling operation.
Solution:
Try to reduce the number calls between the managed and unmanaged code. Consider to do
more work in each call rather than making frequent calls to do small tasks.

DATABASE Improvements:-

1) Return Multiple Resultsets

The database code if has request paths that go to the database more than once then, these
round-trips decreases the number of requests per second your application can serve.
Solution:
Return multiple resultsets in a single database request, so that you can cut the total time spent
communicating with the database. You'll be making your system more scalable, too, as you'll cut
down on the work the database server is doing managing requests.

2) Connection Pooling and Object Pooling

Connection pooling is a useful way to reuse connections for multiple requests, rather than paying
the overhead of opening and closing a connection for each request. It's done implicitly, but you
get one pool per unique connection string. Make sure you call Close or Dispose on a connection
as soon as possible. When pooling is enabled, calling Close or Dispose returns the connection to
the pool instead of closing the underlying database connection.
Account for the following issues when pooling is a part of your design:
? Share connections
? Avoid per-user logons to the database
? Do not vary connection strings
? Do not cache connections

3) Use SqlDataReader Instead of Dataset wherever it is possible

If you are reading a table sequentially you should use the DataReader rather than DataSet.
DataReader object creates a read only stream of data that will increase your application
performance because only one row is in memory at a time.

4) Keep Your Datasets Lean

Remember that the dataset stores all of its data in memory, and that the more data you request,
the longer it will take to transmit across the wire.
Therefore Only put the records you need into the dataset.

5) Unnecessary round trips

How it affects performance:
Round trips significantly affect performance. They are subject to network latency and to
downstream server latency. Many data-driven Web sites heavily access the database for every
user request. While connection pooling helps, the increased network traffic and processing load
on the database server can adversely affect performance.
Solution:
Keep round trips to an absolute minimum.
6) Too many open connections
Connections are an expensive and scarce resource, which should be shared between callers by
using connection pooling. Opening a connection for each caller limits scalability.
Solution:
To ensure the efficient use of connection pooling, avoid keeping connections open and avoid
varying connection strings.

7) Avoid Transaction misuse

How it affects performance:
If you select the wrong type of transaction management, you may add latency to each operation.
Additionally, if you keep transactions active for long periods of time, the active transactions may
cause resource pressure.
Solution:
Transactions are necessary to ensure the integrity of your data, but you need to ensure that you
use the appropriate type of transaction for the shortest duration possible and only where
necessary.

8) Use Sequential Access as Often as Possible

With a data reader, use CommandBehavior.SequentialAccess. This is essential for dealing with
blob data types since it allows data to be read off of the wire in small chunks. While you can only
work with one piece of the data at a time, the latency for loading a large data type disappears. If
you don't need to work the whole object at once, using
Sequential Access will give you much better performance.