Q1.Do you have it compiled in dubug mode?<BR>A1.Yes we are still In debug Mode, later we would chage<BR>Q2.What type of db are you using?<BR>A2.Im using MS sql 2000<BR>Q3.What type of db connectors are you using?<BR>A3.we are using OLEDB connection.<BR>Q4.Are you using complex nested SQL statements?<BR>A4.Yes In some places<BR>Q5.Are you using views or stored procs?<BR>A5.Im using Stored Procs<BR>Q6.What machine are you running it on?<BR>A6.Windows 2000 Server.<BR>Q7.Are there any heavy graphics that have to load?<BR>A8.Well No really but we have DHTML Menu, which Loads in the Page.. ie As include file.(SIze 180KB).<BR>Q9.How large are the resulting html pages that are rendered?<BR>A9.may be (157,324,200 KB's etc..)THis File Size is Excluding the Menu (.Js file[180kb])<BR><BR>Thanx a lot for the Response Mr.OmnyVishalrai,<BR><BR>A couple of suggestions:<BR><BR>1. Running in Release mode might make a huge difference. When you compile in debug mode there are lots of debug symbols that get lumped in with your dll, and of course your app is now aware of it and looking for debug logic and breaks. In your web.config change debug="false" and recompile in release mode to test. You can always switch it back.<BR><BR>2. I don't know much about the performance of the OLEDB Connectors in .net. I have been using the SQLClient connectors because of its optimization for use with SQL 2k. I have been getting great results with 1000's of results.<BR><BR>4. Nested SQL statements have caused bottlenecks for me in the past. Try converting those to views if you can. I have seen serious execution time decreases when converting to views.<BR><BR>5. Good. Stored Procs good
.<BR><BR>6. Good.<BR><BR>7 & 8. I think your downloaded filesize is quite large. 180 k for js for a menu system is pretty darn big, especially when used in conjunction with a 150k + html generated file that contains your data.<BR><BR><BR>I hope this helps 

