نکاتی برای افزایش سرعت صفحات ASP کلاسیک

با سلام

همانطور که می دانید برای اجرای برنامه نوشته شده با زبان های تحت سرور ابتدا دستورات به کار گرفته شده در صفحات٬ در سرور کامپایل شده سپس نتیجه به صورت کدهای HTML در برنامه جستجوگر کاربر نمایش داده می شود. به این ترتیب بعد از ارسال درخواست مشاهده یک صفحه نوشته شده با ASP مدت زمانی طول می کشد تا صفحه مورد نظر نمایش داده شود. در این مقاله قصد داریم راه های گوناگون برای کم کردن این بازه زمانی را مطرح کنیم.

غیر فعال کردن دستور دهنده EnableSessionState :
با استفاده از این دستور دهنده می توانید از ردیابی صفحه مورد نظر خود در طول یک جلسه کاری جلوگیری کنید. غیر فعال کردن این دستور دهنده سبب کاهش مدت زمان لازم برای پردازش اسکریپتها توسط سرور می شود.
برای غیر فعال کردن این دستور دهنده٬ کد زیر را در ابتدایی ترین خط از صفحه قرار دهید:

<% @ EnableSessionState = False %>

لازم به ذکر است با انجام این اینکار دیگر قادر به استفاده از Session در صفحه مورد نظر نخواهید بود و اگر از دستوراتی مانند <% session("anything") = x %> استفاده کنید با خطا مواجه خواهید شد.
با توجه به گفته های بالا واضح است که این عمل تنها برای صفحاتی مناسب است که نیازی به استفاده از Session ها ندارند.

استفاده از Option Explicit :
همانطور که می دانید درصورت استفاده از Option Explicit برنامه نویس ملزم به اعلان کردن متغیرها٬ پیش از استفاده از آنها می باشد. برای مثال به کد زیر توجه کنید:

<%

x = "www.Barnamenevis.com"

response.write x

%>

کد فوق به درستی اجرا می شود ولی اگر در ابتدای این کد عبارت Option Explicit را اضافه کنیم با خطای Variable is undefined روبرو می شویم.
وقتی از این عبارت استفاده نمی شود برنامه به هنگام رسیدن به کدهایی که از متغیرهای اعلان نشده استفاده می کنند مجبور به ساخت نمونه موقتی از هر متغیر می شود. این پروسه باعث افزایش زمان پردازش می شود و به تبع زمان بارگذاری صفحه افزایش می یابد.
لذا بهتر آن است که متغیرهای مورد استفاده خود را پیش از استفاده اعلان کنید.

استفاده از بافر:
همانطور که می دانید استفاده از بافر باعث می شود که ابتدا تمامی کدهای برنامه (در سمت سرور) به کدهای HTML تبدیل شوند و سپس تمامی کدها در یک لحظه به مرورگر وب ارسال شوند. در صورتی که بافر فعال نباشد برای نمایش اطلاعات موجود در یک صفحه ASP هر خط از برنامه به HTML تبدیل شده و در همین حال به مرورگر ارسال می شوند. حال فرض کنید صفحه ما حاوی 10000 خط کد باشد (!!) در چنین حالتی (در صورتی که بافر فعال نباشد) به هنگام باز کردن صفحه شاهد آن خواهیم بود که چند خط از صفحه نمایش داده می شود و بعد از چند لحظه مکث باقی اطلاعات به همین شکل نمایان می شوند. حال اگر بافر را فعال کنیم٬ پیش از نمایش مندرجات صفحه ابتدا کلیه اطلاعات آن به صورت موقت در سرور ذخیره می شود و به یکباره این اطلاعات برای کاربر ارسال می شود و بدین ترتیب تمامی خطوط صفحه در یک لحظه نمایان می شوند.
برای فعال کردن بافر در صفحه از کد زیر استفاده کنید:

Response.Buffer = True

در هر صفحه ASP تنها از یک نوع زبان اسکریپتی استفاده کنید
شاید برایتان عجیب باشد که مگر کسی چنین کاری می کند؟! در جواب این سوال باید گفت "بله". در بعضی از موارد بعضی از برنامه نویسان در یک صفحه ASP از دو زبان اسکریپتی (و شاید بیشتر از دو زبان) استفاده می کنند. برای مثال در ابتدایی ترین خط از برنامه می نویسند:

<%@LANGUAGE="VBSCRIPT">

ولی در جایی از برنامه نیاز به استفاده از کدهای جاوا اسکریپت (شاید به خاطر اینکه معادل کد مورد نیاز خود را در vbs نمی دانند!) دارند و به همین علت با استفاده از تگ <SCRIPT RUNAT=SERVER> اقدام به این کار می کنند.
حال اگر چنین کاری انجام شود چه مشکلی پیش می آید؟
با انجام اینکار در واقع سرور به هنگام ترجمه صفحه جاری می بایست دو نوع کامپایل را انجام دهد و این عمل باعث صرف زمان بیشتری خواهد شد. لذا بهتر آن است پیش از شروع به نوشتن کدهای یک صفحه ASP از تصمیم خود برای انتخاب زبان مورد نیاز مطمئن شویم.
لازم به ذکر است استفاده از زبانهای مختلف در صفحات متفاوت و جدا از هم بلامانع است.

استفاده از response.write به جای استقاده از =
همانطور که می دانید در اغلب موارد به جای استفاده از متد write از معادل آن که همان علامت مساوی (=) است استفاده می شود.
با اینکه کاربرد = راحت تر از write است ولی با این حال نوشتن کد کامل (response.write) به هنگام کامپایل٬ مدت زمان کمتری را نسبت = به خود اختصاص می دهد.

عدم استفاده مجدد و مداوم از توابع و مجموعه های مشابه
این مورد یکی از رایجترین اشتباهات برنامه نویسان عزیز است.
برای مثال کد زیر را مشاهده کنید:

<%

if request.form("num") > 10 then

	response.write "Your selected item is: " & request.form("num") & " (x>10)"

else

	response.write "Your selected item is: " & request.form("num") & " (x<10)"

end if

%>

همانطور که مشاهده می کنید در کد بالا برای نمایش مقدار num در سه بخش متفاوت از کد request.form("num") استفاده شده است. چنین کاری باعث می شود برای بدست آوردن مقدار num در هر بخش کد مربوطه مجددا ترجمه شود و مسلما کاری بیهوده است. بهتر آن است که مقادیر تکراری یک بار فراخوانده شوند و در متغیری ذخیره گردند و در دفعات بعدی تنها از متغیر مذکور استفاده شود.
کد اصلاح شده بدین شکل خواهد بود:

<%

num = request.form("num")

if num > 10 then

	response.write "Your selected item is: " & num & " (x>10)"

else

	response.write "Your selected item is: " & num & " (x<10)"

end if

%>

استفاده از مجموعه های request به طور مناسب
این مورد از آن مواردیست که بعضا مورد توجه قرار نمی گیرد.
ابتدا به نمونه کد زیر توجه نمایید:

<%

dim id

id = request("id")

%>

شیء request از پنج مجموعه تشکیل شده است که عبارتند از : Form ٬ QueryString ٬ ClientCertificates ٬ ServerVariables و Cookies. همه شما با این مجموعه ها آشنایی دارید. همانطور که می دانید برای استفاده از هر یک از این مجموعه ها بدین شکل عمل می شود:

request.CollectionName("Statement")

که در اینجا CollectionName همان نام مجموعه بوده و Statement مقدار مورد نظر می باشد.
حال یکی دیگر از راه های استفاده از مقادیر یک مجموعه (که به عنوان مثال در چند خط بالاتر آورده شد) را یادآوری می کنم. برای استفاده از این روش دیگر نیازی به درج نام مجموعه (CollectionName) نمی باشد و لذا کد بالا به این شکل در می آید:

request("Statement")

تفاوت این دو روش در این است که در روش ابتدایی آدرس دهی کامل انجام شده است و لذا برای ترجمه کد های ASP بدون هیچ مانعی اینکار انجام می شود. ولی در روش دوم به دلیل اینکه نام مجموعه ذکر نشده است٬ سرور به هنگام کامپایل این بخش از کد به ترتیب اولویت مجموعه ها مقدار نوشته شده را در هر مجموعه تست می کند و اولین مقدار برگشتی را به عنوان مقدار معادل کد نوشته شده ذخیره می کند. ترتیب قرار گرفتن مجموعه ها در شیء request بدین شکل است:

1. QueryString

2. Form

3. Cookies

4. ClientCertificates

5. ServerVariables

بدین ترتیب اگر به مقداری در مجموعه ServerVariables نیاز داشته باشیم (و از روش دوم استفاده کنیم)٬ شاهد آن خواهیم بود که ابتدا مقدار ذکر شده در مجموعه QueryString و سپس Form و ... چک می شود و در آخر به ServerVariables می رسد٬ که این مراحل باعث به طول انجامیدن مدت زمات کامپایل می شوند.

در هر صفحه تنها یکبار به یک بانک اطلاعاتی متصل شوید
این مورد به قدری واضح است که به نظرم نیازی به توضیح ندارد. خلاصه آنکه سعیتان را بر این بگذارید که در هر صفحه تنها یکبار به یک بانک اطلاعاتی متصل شوید.

منبع : دقیقا نمیدونم چون فقط متن انگلیسیش رو ذخیره کرده بودم

امیدوارم اطلاعات موجود در این مقاله براتون جالب و مفید بوده باشد.

میزان بهبود در سرعت اجرای صفحات با اعمال تمامی این ملاحظت چقدر است؟ اگر کم باشد فکر نمی‌کنم ارزش داشته باشد؟ با برخی از موارد بسیار موافقم و از نظر برنامه‌نویسی اصولی صحیح‌تر است، اما پرهیز از چیزی مانند مختصرنویسی که آن هم چند بار فقط در صفحه استفاده شده فکر نمی‌کنم تغییر چندانی در سرعت ایجاد کند.

با سلام و خسته نباشید:

من فکر می کنم که برنامه نویسی در asp کلاسیک خیلی کمتر از asp.net از cpu سرور استفاده می کند.

به نظر می آید که برنامه های دات نت خیلی بیشتر احتیاج به کامپایل کردن دارند.

البته این مقایسه در مواقعی است که دو سایت حجم و کارای مساوی داشته باشد.

آیا واقعا دات نت در شرایط مساوی بیشتر cpu سرور را درگیر می کند؟

با تشکر از پاسخ شما اساتید.

دوست عزیز فایل های .net تنها در اولین فراخوانی در سرور کامپایل می شوند و از اون موقع به بعد همین فایل های کامپایل شده به کاربر درخواست کننده صفحه ارسال خواهند شد. بدین ترتیب حجم عملیاتی نسبت به asp کلاسیک که هر بار عملیات کامپایل انجام میشه کمتره!
البته نکته مورد توجه اینه که این موضوع تنها در مورد صفحات با طراحی پیچیده و کدهای زیاد مورد بحث است و در صفحات ساده مسلما چندان بار عملیاتی معنا ندارد.

[quote=kashaneh;594056]. بدین ترتیب حجم عملیاتی نسبت به asp کلاسیک که هر بار عملیات کامپایل انجام میشه کمتره!


پس به این ترتیب اگر یک نفر سایت پربننده ای داشته باشه و کلی صفحات داینامیک مثل یک فروشگاه با کلی صفحه و کلی مشتری که هر صفحه بخواد دائما کامپایل بشه و برای هر کدام از مشتری ها واقعا باید از .net. استفاده کرد. چون فقط اولین بار کامپایل می شه و دیگه برای همه مشتری ها قابل استفاده است.

ولی اگر یک بار کامپایل بشه آیا باز هم می شه به او گفت داینامیک؟

نمی دونم شاید فقط به زبون ماشین ترجمه می شه.

باز هم ممنون

موارد خوبی بود
رعایتش بد نیست
بخصوص استفاده از بافر برای نمایش پروسس بار

با ید از آقای
kashaneh
واقعا تشکر کرد
و آقای
M-Gheibi