We use Page.ParseControl to interpret a string of XML into controls. Does it use some kind of caching mechanism? If not - is there a way to cache its result?
Page.LoadControl seems to support some sort of caching.
There does not seem to be any caching involved.
As a Control is a reference types, caching wouldn't be recommended in this case. (You want a new instance of the control each time you call the ParseControl function)
LoadControl doesn't perform caching per say, but the difference is rather that ParseControl will parse the input string every time to create the control dynamically, while LoadControl will re-use the parsed control template and class type when creating new instances, making it an order of magnitude faster.
Related
Given an outputcache directive like this on a page
<%# OutputCache Duration="3600" VaryByParam="Id" %>
How can I tell what the VaryByParam value is in code.
The HttpContext.Current.Response.Cache.VaryByParams object contains a private _parameters Dictionary and an internal IsVaryByStar property, but without reflecting into the object which I'm fairly loath to do, I can't access them. Is there any standard way to discover what outputcache directives have been set on a particular request?
I don't believe that there would be another way to enumerate parameters. Beside enumerating parameters, you may have to look out for wild-card("*") parameter. So I believe that the simplest way would be to use reflection.
On different note, I am not certain about exact use case that needs such requirement. Couple of alternative approaches may or may not suite you requirements are
Build your own control/extender to accept caching parameters (instead of OutputCache directive) and then modify Response.Cache in early page life cycle.
Use brute-force attack by building dictionary of all possible parameters (but wild-card support may spoil this because in such case Response.Cache.Item will return true for all parameters). Possible alternative is to force page to give its cache parameters by introducing an abstract method from base page class.
Hi
I want to increase the performance of asp.net application when multiple user access my application about 5000 users.
Can we do this
Your ASP.NET application performance depends on various things. You can improve your site's performance by doing various stuff. Your questions is very subjective and of course the answer would be some best practices about improving ASP.NET applications' performance.
I have gathered some tips from the net. Unfortunately, I cannot remember where. Search on any item and you will find many resources that can help you implement it:
Use Cache:
Page output caching.
Page fragment caching.
Data caching.
Avoid frequent trips to database.
Use DB-level paging. Don't retrieve unnecessary data that's not going to be shown in the current page.
Be careful with Session variables. Usually, you should avoid session variables because each ASP page runs in a different thread and session calls will be serialized one by one. So, this will slow down the application. Instead of session variables you can use the QueryString collection or hidden variables in the form which holds the values.
Select the Release mode before making the final Build for your application.
Set debug=false under compilation: <compilation default Language="c#" debug="false">
Avoid Inline JavaScript and CSS
Use Finally Method to kill resources. (But not in the case of using)
Avoid Exceptions: Use If condition (if it is check proper condition)
Check “Page.IsPostBack”. To avoid repetition code execution.
Use single css file instead of multiple css file.
Use Client-Side Validation. (but not all the time you have to validate even on the server side).
Turn off Tracing unless until required.
Turn off Session State, if not required.
Disable ViewState when not required.
Try to use StringBuilder instead of string.
It is nice to use Stringbuilder instead of String when string are Amended. Strings occupy different memory location in every time of amended where stringbuilder use single memory location.
Never use object value directly; first get object value in local variable and then use. It takes more time then variable reading.
Avoid using code like x = x +1; it is always better to use x+=1.
Data Access Techniques: DataReaders provide a fast and efficient method of data retrieval. DataReader is much faster than DataSets as far as performance is concerned. But that depends on you deciding to balance between features/performance.
Use Repeater control instead of DataGrid , DataList, Because It is efficient, customizable, and programmable.
Reduce cookie size.
Compress CSS, JavaScript and Images.
Use server side compression software such as Port80s
Make your page files as light as possible. That is try to avoid unnecessary markups, e.g. use div elements instead of tables.
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.
Retrieve necessary 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.
Remove blank spaces from your html it will increase your kb. You can use regular expression to remove white spaces. I will post the code for removing white spaces next posts.
For asp.net 2.0 and higher version use master pages. It will increase your performance.
Use ADO.NET asynchronous calls for ado.net methods. asp.net 2.0 or higher version is supporting your performance. If you are using same procedure or command multiple time then use ADO.NET Prepare command it will increase your performance.
Do IIS performance tuning as per your requirement.
Disable view state for your controls if possible. If you are using asp.net 2.0 or higher version then use asp.net control state instead of view state. Store view state in session or database by overriding the default methods for storing view state
Use Ajax for your application wisely. Lots of Ajax calls for a page will also decrease your performance.
Call web service from java script instead of server side. Use asynchronous calls to call a web method from web service.
One reason we currently use UpdatePanels for doing our AJAX is because our BL and DA layers pass around the Page.User.Identity for authentication.
Is there a way to access this?
Yes, you can get the current user via HttpContext.Current.User. From the MSDN documentation for Page.User:
This property uses the HttpContext
object's User property to determine
where the request originates.
As for your broader question, "How can I use jQuery Ajax and PageMethods with instance variables?" The answer is "not directly."
No instance of your page is created when executing a page method. (Why do ASP.NET AJAX page methods have to be static? is a great conceptual overview of the differences between normal page operations and static page methods).
The only way to access instance variables in page methods is to first put the variables into Session during the initial page request - but this is a rather fragile strategy: you're better off figuring out another way to get the data or values in question.
I agree with Jeff Sternal's answer to this post. On my current project, we frequently use the session as a "scratch pad" to store data for later use by PageMethods and ASMX webservices.
However, if you don't like using session in that fashion, here is another approach that should be a viable alternative:
At page-creation time, you can put instance variable values into javascript vars or hidden fields. From there, they can easily be accessed by javascript/jquery and included as params on calls to webservices. You could then code your webservices (PageMethods, ASMX services or others) to take those values as parameters.
ViewState Caching
This is a great idea, but it's implemented for SharePoint. Wonder if there is a solution for regular asp.net pages, which does the same, caches viewstates.
It's actually quite simple! You just need to override these two methods on your page:
SavePageStateToPersistentMedium()
LoadPageStateFromPersistenceMedium()
In there, you can get the ViewState object tree, serialize it however you want and store it wherever you want (Session, SQL, etc), and instead of returning the entire serialized blob to the browser, just return a unique ID you can use to look it up again next time around.
The idea is covered in painstaking detail here: http://msdn.microsoft.com/en-us/library/ms972976.aspx
It is quite possible through overriding the below two methods in
asp.net System.Web.UI.Page:
SavePageStateToPersistentMedium()
LoadPageStateFromPersistenceMedium()
While in the first method you need to check if the ViewState already exists in the cache and if not save it there, in the second method you can retrieve it if it is already there.
You can concatenate the SessionID and the pageName as the key for the cache viewStateKey.
I have been using Request.Form for all my code. And if I need querystring I hit that explicitly too. It came up in a code review that I should probably use the Params collection instead.
I thought it was a best practice, to hit the appropriate collection directly. I am looking for some reinforcement to one side or the other of the argument.
It is more secure to use Request.Form. This will prevent users from "experimenting" with posted form parameters simply by changing the URL. Using Request.Form doesn't make this secure for "real hackers", but IMHO it's better to use the Form collection.
By using the properties under the request you are narrowing down the your retrieval to the proper collection (which is a good thing for readability and performance). I consider your approach to be a best practice and follow it myself.
I have always used
Request.Form("Param")
or
Request.QueryString("Param")
This is purely down to a syntax which is easier to read. I seriously doubt there is a performance impact.
The only time I use Request.Params instead of Form or Querystring is if I don't know whether the method by which the parameters will be passed in.
To put that in context, in 10 years I have used Request.Params in anger only once :)
Kindness,
D
I think it's better to use the Form and QueryString collections explicitly unless you're explicitly trying to define flexible behavior in your application like in a search form where you might want to have the search parameters definable in a URL or saved in cookies such as pagination preferences.
I would use Request.Form and Request.QueryString explicitly. The reason is that the two are not interchangable. The query string is used for HTTP Get requests, and FORM variables for HTTP post requests.
Get requests are typically applicable where you are requesting data, e.g. do a google search, the search words are in the query string. The post are when you are sending data to the web server for processing or storing. So when I say that the two are not interchangable I mean that you cannot change the page from using a GET to a POST without breaking functionality.
So IMHO, the implementation of the page can quite clearly reflect the fact that you intend it to be called by a GET or a POST request.
/Pete