Now, I don't claim to have all the answers, nor will I say that all my answers are correct, but what this post is about are the ways to optimize your code. These are just things that I have observed either through practice, or read somewhere. I have linked this to an FAQ, but the reason that I have made this into a post is because I want this document to grow. Like I said, I don't know all the possible ways to optimize your application... I was hoping to get some help from the other members through their additions to this post. This is presented in completely random order.
Data source
- Just by optimizing your database, you can gain some significant speed.
- If you use a DB that supports Stored Procedures, USE THEM RELIGOUSLY. Not only will your ASP code see a significant speed increase, it also becomes alot easier to update your application.
- If you use something like Access, realize that the more joins you have, the less efficient your query will be. This comes with a tradeoff though, since you lose a lot of the natural benefits of normalizing your database.
- Don't do "SELECT * ..." if you don't need all the columns. Specify the columns you need, it saves processing time.
File extensions
- If your page does not have any ASP code on it, do not save it with an .asp extension, save it as .htm or .html.
- If your page has no ASP code, but only has include directives, save it with a .shtm or .shtml extension.
- This is good because if you don't need the dll's functionality, then don't incur the overhead of loading the asp or include processing dlls.
Global.asa
- If you use adovbs.inc anywhere, load the type library. The speed change for this is immediately noticed. Thanks to link9 for bringing this point to light. If you need to know how to load the adovbs.inc meta library, check thread333-81602.
- Do not give ADO Connection objects Application or Session state. Doing so increases the thread affinity and reduces the application's scalability.
- Do store your connection strings in the Global.asa. This isn't a steadfast speed increase, but I've always found that it makes life a whole lot easier when you change anything in your data access technique.
Read this
I'll probably end up reiterating points that were stated in the MSDN article, but I know that I won't cover everything. Read it for some great optimization tips.
ASP Code
- Avoid string concatination in VBScript. It's extremely slow... if you need to do heavy string concatination, use a separate component for it.
- If you're willing to do it, use JScript for your pages. I've read benchmarks where JScript outperforms VBScript in every category except for string manipulation. Unfortunately, alot of legacy ASP code and most of the examples you see out are in VBS.
- Use functions. Don't give variables page scope if they don't need it. Give them local scope, and it should be easier on your application. Plus, you can reuse 'i' (for i = 0 to ...)
- Use Option Explicit. Not only does it help your app speed, it also helps you debug.
- If IIS is setup to use VBScript as it's default scripting language, remove the <%@LANGUAGE=VBScript%> from the top of your pages. Again, why process server-side directives if you don't need to. If you use JScript, specify it as your default IIS language, then remove the @LANGUAGE directive.
ASP objects
- When using Request, specify .Form or .QueryString. I've heard there is a slight performance hit by not specifying the collection, so specify the collection. I only use Request(".." when absolutely necessary.
- Concatinate your Response.writes. If you concat a string, then response.write that string, see if there's a way you can just write everything out to the screen. You avoid the overhead of string concatination, which is a very good thing.
- Use Response.buffer at the beginning of your pages. This way IIS can process the entire page then output to the browser, as opposed to sending the output as it's done. If you need to show some of the page, use Response.Flush to flush out the contents.
- Only create objects if you need them. Also, set all objects = nothing when you are done with them.
ADO Objects
This is where you should be able to get the most performance increases. The connection stuff is especially important regarding people who have Access databases on the backend. Access cannot handle multiple current connections very effectively, so you need to try to keep your connections open as little as possible.
- If you are updating your DB, do not use the recordset to issue the update. Instead, use conn.execute sqlstatement. It'll save you the cost of creating the recordset object when you don't need to. Remember, that Access 2000 allows you to get @@IDENTITY, so if you need the just inserted pk, you can get it that way.
- Use .GetRows and .GetString. Using both allow you to get all of the rs information stored into memory, then you can free up the connection and recordset objects very quickly.
- If you need to do a lot of recordset manipulation, consider disconnecting the recordset from the data source.
I *know* there are other ways to optimize your ASP... I just can't think of them now. Please -- if there's anything else that you know, contribute to this post.
hth someone
leo
Data source
- Just by optimizing your database, you can gain some significant speed.
- If you use a DB that supports Stored Procedures, USE THEM RELIGOUSLY. Not only will your ASP code see a significant speed increase, it also becomes alot easier to update your application.
- If you use something like Access, realize that the more joins you have, the less efficient your query will be. This comes with a tradeoff though, since you lose a lot of the natural benefits of normalizing your database.
- Don't do "SELECT * ..." if you don't need all the columns. Specify the columns you need, it saves processing time.
File extensions
- If your page does not have any ASP code on it, do not save it with an .asp extension, save it as .htm or .html.
- If your page has no ASP code, but only has include directives, save it with a .shtm or .shtml extension.
- This is good because if you don't need the dll's functionality, then don't incur the overhead of loading the asp or include processing dlls.
Global.asa
- If you use adovbs.inc anywhere, load the type library. The speed change for this is immediately noticed. Thanks to link9 for bringing this point to light. If you need to know how to load the adovbs.inc meta library, check thread333-81602.
- Do not give ADO Connection objects Application or Session state. Doing so increases the thread affinity and reduces the application's scalability.
- Do store your connection strings in the Global.asa. This isn't a steadfast speed increase, but I've always found that it makes life a whole lot easier when you change anything in your data access technique.
Read this
I'll probably end up reiterating points that were stated in the MSDN article, but I know that I won't cover everything. Read it for some great optimization tips.
ASP Code
- Avoid string concatination in VBScript. It's extremely slow... if you need to do heavy string concatination, use a separate component for it.
- If you're willing to do it, use JScript for your pages. I've read benchmarks where JScript outperforms VBScript in every category except for string manipulation. Unfortunately, alot of legacy ASP code and most of the examples you see out are in VBS.
- Use functions. Don't give variables page scope if they don't need it. Give them local scope, and it should be easier on your application. Plus, you can reuse 'i' (for i = 0 to ...)
- Use Option Explicit. Not only does it help your app speed, it also helps you debug.
- If IIS is setup to use VBScript as it's default scripting language, remove the <%@LANGUAGE=VBScript%> from the top of your pages. Again, why process server-side directives if you don't need to. If you use JScript, specify it as your default IIS language, then remove the @LANGUAGE directive.
ASP objects
- When using Request, specify .Form or .QueryString. I've heard there is a slight performance hit by not specifying the collection, so specify the collection. I only use Request(".." when absolutely necessary.
- Concatinate your Response.writes. If you concat a string, then response.write that string, see if there's a way you can just write everything out to the screen. You avoid the overhead of string concatination, which is a very good thing.
- Use Response.buffer at the beginning of your pages. This way IIS can process the entire page then output to the browser, as opposed to sending the output as it's done. If you need to show some of the page, use Response.Flush to flush out the contents.
- Only create objects if you need them. Also, set all objects = nothing when you are done with them.
ADO Objects
This is where you should be able to get the most performance increases. The connection stuff is especially important regarding people who have Access databases on the backend. Access cannot handle multiple current connections very effectively, so you need to try to keep your connections open as little as possible.
- If you are updating your DB, do not use the recordset to issue the update. Instead, use conn.execute sqlstatement. It'll save you the cost of creating the recordset object when you don't need to. Remember, that Access 2000 allows you to get @@IDENTITY, so if you need the just inserted pk, you can get it that way.
- Use .GetRows and .GetString. Using both allow you to get all of the rs information stored into memory, then you can free up the connection and recordset objects very quickly.
- If you need to do a lot of recordset manipulation, consider disconnecting the recordset from the data source.
I *know* there are other ways to optimize your ASP... I just can't think of them now. Please -- if there's anything else that you know, contribute to this post.
hth someone
leo