مروري بر تاريخچه محدوديت حافظه مصرفي برنامه‌هاي ASP.NET در IIS

زمانيكه اولين نگارش ASP.NET‌ حدود 10 سال قبل منتشر شد،‌ تنها سيستم عاملي كه از آن پشتيباني مي‌كرد، ويندوز سرور 2000 بود، تنها پروسه‌ي اجرايي آن aspnet_wp نام داشت و تنها معماري پشتيباني شده هم X86 بود. به پروسه‌ي aspnet_wp محدوديت مصرف حافظه‌اي اعمال شده بود كه در حين آغاز آن بر اساس مقدار قابل تغيير processModel memoryLimit محاسبه و اعمال مي‌شد (تعريف شده در فايل ماشين كانفيگ). اين عدد به صورت درصدي از ظرفيت RAM فيزيكي سيستم، قابل تعريف و به صورت پيش فرض به 60 درصد تنظيم شده بود. به اين ترتيب اين پروسه مجاز نبود تا تمام حافظه‌ي فيزيكي مهيا را مصرف كند و در صورت وجود نشتي حافظه‌اي در برنامه‌اي خاص، اين پروسه امكان بازيابي مجدد حافظه را پيدا مي‌كرد (recycling). همچنين يك مورد ديگر را هم بايد در نظر داشت و آن هم وجود قابليتي است به نام ASP.NET Cache است كه امكان ذخيره سازي مقادير اشياء را در حافظه‌ي مصرفي اين پروسه مهيا مي‌سازد. هر زمان كه ميزان اين حافظه‌ي مصرفي به حد نزديكي از محدوديت تعريف شده برسد، اين پروسه به صورت خودكار شروع به حذف آن‌ها خواهد كرد.
محدوديت 60 درصدي تعريف شده، براي سيستم‌هايي با ميزان RAM كم بسيار مفيد بود اما در سيستم‌هايي با ميزان RAM بيشتر، مثلا 4 گيگ به 2.4GB حافظه مهيا (60 درصد حافظه فيزيكي سيستم) محدود مي‌شد و همچنين بايد در نظر داشت كه ميزان user mode virtual address space مهيا نيز تنها 2 گيگابايت بود. بنابراين هيچگاه استفاده مؤثري از تمام ظرفيت RAM مهيا صورت نمي‌گرفت و گاها مشاهده مي‌شد كه يك برنامه تنها با مصرف 1.5GB RAM مي‌توانست پيغام OutOfMemoryException را صادر كند. در اين حالت مطابق بررسي‌هاي صورت گرفته مشخص شد كه اگر مقدار processModel memoryLimit به حدود 800 مگابايت تنظيم شود، بهترين عملكرد را براي سيستم‌هاي مختلف مي‌توان مشاهده كرد.

با ارائه‌ي ويندوز سرور 2003 و همچنين ارائه‌ي نسخه‌ي 1.1 دات نت فريم ورك و ASP.NET ، اين وضعيت تغيير كرد. پروسه‌ي جديد در اينجا w3wp نام دارد و اين پروسه تعاريف مرتبط با محدوديت حافظه‌ي خود را از تنظيمات IIS دريافت مي‌كند (قسمت Maximum Used Memory در برگه‌ي Recycling مربوط به خواص Application Pool مرتبط). متاسفانه اين عدد به صورت پيش فرض محدوديتي ندارد و به ظاهر برنامه مجاز است تا حد امكان از حافظه‌ي مهيا استفاده كند. به همين جهت يكي از مواردي را كه بايد در نظر داشت، مقدار دهي Maximum Used Memory ذكر شده است. خصوصا اينكه در نگارش 1.1 ، تنظيمات ميزان مصرف RAM مرتبط با ASP.NET Cache نيز با برنامه يكي است.

در نگارش 2.0 دات نت فريم ورك، تنظيمات مرتبط با ASP.NET cache از تنظيمات ميزان RAM مصرفي يك برنامه‌ي ASP.NET جدا شد و اين مورد توسط قسمت cache privateBytesLimit قابل تنظيم و مديريت است (در فايل IIS Metabase و همچنين فايل web.config برنامه).

نكته!
اگر process memory limit و همچنين cache memory limit را تنظيم نكنيد، باز به همان عدد 60 درصد سابق بازخواهيم گشت و اين مورد به صورت خودكار توسط IIS محاسبه و اعمال مي‌شود. البته محدوديت ذكر شده براي پروسه‌هاي 64 بيتي در اين حالت بسيار بهتر خواهد بود. اگر هر دوي اين‌ها را تنظيم كنيد، عدد حداقل بكارگرفته شده، مبناي كار خواهد بود و اگر تنها يكي را تنظيم كنيد ، اين عدد به هر دو حالت اعمال مي‌گردد. براي بررسي بهتر مي‌توان به مقدار Cache.EffectivePrivateBytesLimit و Cache.EffectivePercentagePhysicalMemoryLimit مراجعه كرد.

و ... اكنون بهتر مي‌توانيد به اين سؤال پاسخ دهيد كه «سرور ما بيشتر از 4 گيگ رم دارد و برنامه‌ي ASP.NET من الان فقط 850 مگ رم مصرف كرده (كه البته اين هم نشاني از عدم dispose صحيح منابع است يا عدم تعيين تقدم و تاخر و زمان منقضي شدن، حين تعريف اشياء كش)، اما پيغام out of memory exception را دريافت مي‌كنم. چرا؟!»


بنابراين ايجاد يك Application pool جديد به ازاي هر برنامه‌ي ASP.NET امري است بسيار مهم زيرا:
- به اين ترتيب هر برنامه‌ي ASP.NET در پروسه‌اي ايزوله از پروسه‌ي ديگر اجرا خواهد شد (اين مساله از لحاظ امنيتي هم بسيار مهم است). در اينجا هر برنامه، از پروسه‌ي w3wp.exe مجزاي خاص خود استفاده خواهد كرد (شبيه به مرورگرهايي كه هر tab را در يك پروسه جديد اجرا مي‌كنند).
- اگر پروسه‌اي به حد بالاي مصرف حافظه‌ي خود رسيد با تنظيمات انجام شده در قسمت recycling مرتبط با Application pool اختصاصي آن، به صورت خودكار كار بازيابي حافظه صورت مي‌گيرد و اين امر بر روي ساير برنامه‌ها تاثير نخواهد داشت (كاربران ساير برنامه‌ها مدام شكايت نمي‌كنند كه سشن‌ها پريد. كش خالي شد. زيرا در حالت وجود application pool اختصاصي به ازاي هر برنامه، مديريت حافظه برنامه‌ها از هم ايزوله خواهند بود)
- كرش صورت گرفته در يك برنامه به دليل عدم مديريت خطاها، بر روي ساير برنامه‌ها تاثير منفي نخواهد گذاشت. (زمانيكه ASP.NET worker process به دليل استثنايي مديريت نشده خاتمه يابد بلافاصله و به صورت خودكار مجددا «وهله‌ي ديگري» از آن شروع به كار خواهد كرد؛ يعني تمام سشن‌هاي قبلي از بين خواهند رفت؛ كه در صورت ايزوله سازي ذكر شده، ساير برنامه‌ها در امان خواهند ماند؛ چون در پروسه ايزوله‌ي خود مشغول به كار هستند)
- با وجود application pool اختصاصي به ازاي هر برنامه، مي‌توان براي سايت‌هاي كم ترافيك و پرترافيك، زمان‌هاي recycling متفاوتي را اعمال كرد. به اين ترتيب مديريت حافظه‌ي بهتري قابل پياده سازي مي‌باشد. همچنين در اين حالت مي‌توان مشخص كرد كدام سايت از تعداد worker process بيشتر يا كمتري استفاده كند.
- كاربري كه پروسه‌ي ASP.NET تحت آن اجرا مي‌شود نيز همينجا تعريف مي‌گردد. بنابراين به اين ترتيب مي‌توان به برنامه‌اي دسترسي بيشتر و يا كمتر داد، بدون تاثير گذاري بر روي ساير برنامه‌هاي موجود.

نتيجه گيري:
- از IIS استفاده مي‌كنيد؟ آيا مي‌دانيد Application pool چيست؟
- آيا مي‌دانيد در صورت عدم مقدار دهي پارامترهاي حافظه‌ي يك Application pool ، به صورت پيش فرض چند درصد از حافظه‌ي فيزيكي مهيا در اختيار شما است؟


براي مطالعه بيشتر:

• CLR processModel memoryLimit

• Some history on the ASP.NET cache memory limits

• Managing Application Pools in IIS 7

بررسي علت CPU Usage بالاي برنامه در حال اجرا

فرض كنيد به يك سرور مراجعه كرده‌ايد و شكايت از CPU Usage مربوط به پروسه w3wp.exe يا همان IIS Worker Process است كه بالاي 90 درصد مي‌باشد. بر روي اين سرور هم هيچ چيز ديگري نصب نيست و مطابق مقررات موجود، قرار هم نيست كه برنامه‌اي نصب شود. اكنون سؤال اين است كه چطور تشخيص مي‌دهيد، كدام قسمت يكي از برنامه‌ها‌ي دات نتي در حال اجرا (در اينجا يكي از برنامه‌هاي ASP.NET هاست شده)، سبب بروز اين مشكل شده است؟ كدام ترد بيشترين زمان CPU را به خود اختصاص داده است؟ چطور بايد خطايابي كرد؟
اولين كاري كه در اين موارد توصيه مي‌شود مراجعه به برنامه‌ي معروف process explorer و بررسي برگه‌ي threads آن است. در اينجا حتي مي‌توان call stacks مرتبط با يك ترد را هم مشاهده كرد. اما ... اين برگه در مورد پروسه‌ها و تردهاي دات نتي، اطلاعات چنداني را در اختيار ما قرار نمي‌دهد.
خوشبختانه امكان ديباگ پروسه‌هاي دات نتي در حال اجرا توسط كتابخانه‌ي MdbgCore.dll پيش بيني شده است. اين فايل را در يكي از مسير‌هاي ذيل مي‌توانيد پيدا كنيد:

C:\Program Files\Microsoft SDKs\Windows\vXYZ\bin\MdbgCore.dll
C:\Program Files\Microsoft SDKs\Windows\vXYZ\bin\NETFX 4.0 Tools\MdbgCore.dll

در ادامه مي‌خواهيم توسط امكانات اين كتابخانه، به stack trace تردهاي در حال اجراي يك برنامه دات نتي دسترسي پيدا كرده و سپس نام متدهاي مرتبط را نمايش دهيم:

using System;
using System.Collections;
using System.Diagnostics;
using Microsoft.Samples.Debugging.MdbgEngine;

namespace CpuAnalyzer
{
   class Program
   {
       static void Main(string[] args)
       {
           var engine = new MDbgEngine();

           var processesByName = Process.GetProcessesByName("MyApp");
           if (processesByName.Length == 0)
               throw new InvalidOperationException("specified process not found.");
           var processId = processesByName[0].Id;

           var process = engine.Attach(processId);
           process.Go().WaitOne();

           foreach (MDbgThread thread in (IEnumerable)process.Threads)
           {
               foreach (MDbgFrame frame in thread.Frames)
               {
                   if (frame == null || frame.Function == null) continue;
                   Console.WriteLine(frame.Function.FullName);
               }
           }

           process.Detach().WaitOne();
       }
   }
}

در اينجا در ابتدا نياز است تا pid يا process-id مرتبط با برنامه در حال اجرا يافت شود. سپس از اين pid جهت اتصال (engine.Attach) به پروسه مورد نظر استفاده خواهيم كرد. در ادامه كليه تردهاي اين پروسه در حال ديباگ ليست شده و سپس MDbgFrameهاي اين ترد بررسي مي‌شوند و نام متدهاي مرتبط در كنسول نمايش داده خواهند شد.
خوب در مرحله بعد شايد بد نباشد كه اين متدها را بر اساس CPU usage آن‌ها مرتب كنيم. به اين ترتيب بهتر مي‌توان تشخيص داد كه كدام متد مشكل ساز بوده است. براي اين منظور بايد به API ويندوز و تابع GetThreadTimes مراجعه كرد و اولين پارامتر ورودي آن، همان thread.CorThread.Handle اولين حلقه مثال فوق مي‌باشد. هر كدام كه جمع KernelTime + UserTime بيشتري داشت، همان است كه مشكل درست كرده است.

[DllImport("kernel32.dll", CharSet = CharSet.Auto, SetLastError = true)]
public static extern bool GetThreadTimes(IntPtr handle, out long creation, out long exit, out long kernel, out long user);

اين مورد را به عنوان تمرين بررسي كرده و ادامه دهيد! همچنين بهتر است جهت دستيابي به اطلاعاتي معتبر، اولين حلقه برنامه فوق، حداقل 10 بار اجرا شود تا اطلاعات آماري بهتري را بتوان ارائه داد. البته در اين حالت نكته‌ي زير بايد رعايت شود:

for (int i = 0; i < 10; i++)
{
   foreach (MDbgThread thread in (IEnumerable)process.Threads)
   {
     //...
   }
   process.Go();
   Thread.Sleep(1000);
   process.AsyncStop().WaitOne();
}

در كل اين مثال جاي كار زياد دارد. براي مثال طراحي يك رابط كاربري براي آن و نمايش جزئيات بيشتر. به همين منظور حداقل سه پروژه مشابه را مي‌توان نام برد:

• Managed Stack Explorer

• CLR Stack Explorer

• CPU-analyzer

تازه‌هاي سرويس پك يك VS 2010 ؛ يكپارچگي با IIS Express

در مورد تنظيمات دستي IIS Express كه يك نسخه‌ي سبك IIS 7.5 قابل اجرا بر روي ويندوز XP نيز مي‌باشد، پيشتر در اين سايت مطلبي را مطالعه كرده‌ايد (+). اكنون كه سرويس پك يك VS 2010 ارائه شده (+)، ديگر نيازي به آن تنظيمات دستي نبوده و امكان استفاده يكپارچه و خودكار از اين نسخه‌ي ساده شده IIS 7.5 به شرح زير وجود دارد:

ابتدا نياز است تا هر دو مورد سرويس پك يك VS 2010 و همچنين IIS Express به صورت جداگانه نصب شوند. سپس:

الف) ابتدا از منوي Tools‌ ، گزينه‌ي Options را انتخاب كنيد. در صفحه‌ي باز شده در قسمت Projects and solutions ذيل گزينه‌ي Web projects نياز است تا يكبار مجوز استفاده از IIS express صادر شود:

ب) اكنون بر روي نام پروژه در Solution explorer موجود در Visual studio كليك راست كرده و گزينه‌ي Use IIS Express را انتخاب نمائيد:

به اين صورت تنظيمات لازم به صورت خودكار اعمال خواهد گرديد و جهت مشاهده آن‌ها مي‌توان به خواص پروژه، برگه‌ي Web مراجعه كرد:

نكته مهم:
نسخه‌ي RTM ويژوال استوديوي 2010 تنظيمات فوق را كه در تصوير ملاحظه مي‌كنيد، ندارد. به عبارتي پس از اعمال تغييرات فوق بايد دقت داشت سايريني كه قرار است از پروژه‌ي شما استفاده كنند نيز بايد پيشنيازهاي ذكر شده را رعايت نمايند و يا جهت توزيع سورس مي‌توان مجددا بر روي نام پروژه كليك راست كرده و اينبار گزينه‌ي Use Visual Studio Development Server قديمي را انتخاب كرد.

استفاده از IIS Express 7.5 در VS.NET

استفاده از IIS در VS.NET و پروژه‌هاي ASP.NET داستان خودش را دارد. در نگارش‌هاي 2002 و 2003 آن، تنها وب سرور قابل استفاده جهت كار با VS.NET همان IIS اصلي بود. مهم‌ترين مشكل اين روش، نياز به داشتن دسترسي مديريتي بر روي سيستم بود (كه در بعضي از شركت‌ها، اين مورد براي عموم كاربران ممنوع است) به همراه نصب جداگانه‌ و تنظيمات مخصوص IIS ، صرفا جهت آزمايش يك برنامه‌ي ساده؛ همچنين با توجه به اينكه IIS جزو كامپوننت‌ها ويندوز بوده و هر نگارشي، IIS خاص خودش را دار است، اين مورد هم مشكلات ويژه‌اي را به همراه دارد (براي مثال IIS5 ويندوز XP را با IIS7 ويندوز سرور 2008 در نظر بگيريد؛ يكي براي توسعه يكي جهت محيط كاري). اين روش در VS.Net 2005 كنار گذاشته شد و از وب سرور توكاري به نام Cassini يا ASP.NET Development Server استفاده گرديد. به اين صورت ديگر نيازي به نصب مجزاي IIS كامل جهت آزمايش‌ برنامه‌هاي ASP.NET نبود و همچنين نياز به داشتن دسترسي مديريتي الزامي نيز منتفي گرديد. اين روش هنوز هم تا نگارش 2010 ويژوال استوديو مرسوم است؛ اما ... اما كساني كه با Cassini كار كرده باشند مي‌دانند كه يك سري از رفتار‌هاي آن با IIS واقعي تطابق ندارد و اگر برنامه‌ي ASP.NET شما با Cassini خوب نمايش داده مي‌شود الزامي ندارد كه با IIS واقعي هم به همان نحو رفتار كند، براي نمونه رفتار مسيريابي آدرس‌هاي نسبي در IIS واقعي و Cassini يكي نيست. علاوه بر آن IIS هاي 7 و 7.5 هم امكانات و ويژگي‌هاي خاص خود را دارند كه Cassini آن‌ها را پوشش نمي‌دهد؛ به علاوه اين دو فقط در ويندوزهاي جديد مانند ويندوز سرور 2008 يا ويندوز 7 قابل دسترسي هستند. به همين جهت اخيرا يك نسخه‌ي سبك و express از IIS 7.5 به صورت جداگانه براي برنامه نويس‌ها فقط جهت آزمودن برنامه‌هاي خود تهيه شده‌ است و البته هدفگيري اصلي آن پروژه‌ي WebMatrix است؛ به همراه ويژگي‌هاي جديد IIS7 مانند امكان آزمودن تنظيمات ويژه IIS7 در وب كانفيگ برنامه، پشتيباني كامل از SSL ، Url Rewrite و ساير ماژول‌هاي IIS7، عدم نياز به دسترسي مديريتي براي اجراي آن، امكان اجراي آن بر روي پورت‌هاي مختلف بدون تداخل با وب سرور(هاي) موجود بر روي سيستم و همچنين برخلاف IIS7 اصلي، بر روي ويندوز XP نيز قابل اجرا است. حجم نگارش IIS Express 7.5 تنها 3.9 مگابايت است:

Internet Information Services (IIS) 7.5 Express

سرويس پك يك ويژوال استوديوي 2010 (كه در زمان نگارش اين مطلب نسخه‌ي بتاي آن ارائه شده)، يك گزينه‌ي جديد را به منوي كليك راست بر روي نام پروژه در VS.NET به نام Use IIS Express ، اضافه كرده است تا به سادگي بتوان از اين امكان جديد استفاده كرد (يا به عبارتي با IIS Express يكپارچه است و نياز به تنظيم خاصي ندارد).
در ساير حالات (و نسخه‌هايي كه اين يكپارچگي وجود ندارد و نخواهد داشت) به صورت زير مي‌توان عمل كرد:
روش اول:
دستور زير را در خط فرمان وارد نمائيد:

"C:\Program Files\IIS Express\iisexpress.exe" /path:D:\Prog\1389\MySite\ /port:4326 /clr:v4.0

به اين صورت وب سروري جهت ارائه‌ي سايتي با مسير ذكر شده بر روي پورت 4326 (http://localhost:4326/) بر اساس دات نت 4 تشكيل خواهد شد (براي نمونه جهت دات نت سه و نيم مقدار v3.5 را وارد نمائيد).

روش دوم (كه در حقيقت همان روش اول با ارائه‌ي پشت صحنه‌ي موقت آن است):
الف) ابتدا به مسير My Documents\IISExpress\config مراجعه كرده و فايل applicationhost.config را باز كنيد. سپس گره مربوط به site را يافته (حدود سطر 153) و گزينه‌ي serverAutoStart را حذف كنيد:

<site name="WebSite1" id="1">
              <application path="/">
                  <virtualDirectory path="/" physicalPath="%IIS_SITES_HOME%\WebSite1" />
              </application>
              <bindings>
                  <binding protocol="http" bindingInformation=":8080:localhost" />
              </bindings>
</site>

ب) سپس تنظيمات سايت مورد نظر خود را به صورت دستي به اين فايل اضافه كنيد. براي مثال:

<site name="WebSite2" id="2">
              <application path="/" applicationPool="Clr4IntegratedAppPool">
                  <virtualDirectory path="/" physicalPath="D:\Prog\1389\MyTestSite\" />
              </application>
              <bindings>
                  <binding protocol="http" bindingInformation=":1389:localhost" />
              </bindings>
</site>

توضيحات:
Name در اينجا نامي دلخواه است كه وارد خواهيد نمود.
Id شماره سايتي است كه ثبت خواهد شد.
applicationPool در اينجا بسيار مهم است. اگر سايت شما مبتني بر دات نت 4 است، Clr4IntegratedAppPool را وارد نمائيد و اگر غير از اين است، Clr2IntegratedAppPool بايد تنظيم شود.
physicalPath همان مسير پروژه شما است.
در قسمت bindingInformation هم مي‌توان شماره پورت مورد نظر را وارد كرد.

اكنون فايل applicationhost.config را ذخيره كرده و ببنديد.
سپس دستور زير را در خط فرمان ويندوز وارد نمائيد:

"C:\Program Files\IIS Express\iisexpress.exe" /site:WebSite2

كه در اينجا WebSite2 همان مدخل جديدي است كه به فايل applicationhost.config اضافه شده است. به اين صورت آدرس http://localhost:1389/ جهت دسترسي به سايت شما آماده استفاده خواهد بود.

تنظيمات ديباگر VS.NET :
تا اينجا تنها موفق شده‌ايم كه اين وب سرور آزمايشي را راه اندازي كنيم. اما نكته‌ي مهم امكان ديباگ كردن برنامه توسط آن‌را از دست داده‌ايم. براي اين منظور در VS.NET به خواص پروژه، برگه‌ي Web آن مراجعه كنيد. در قسمت Servers گزينه‌ي use custom web server را انتخاب كرده و آدرسي را كه در يكي از دو روش فوق ساخته‌ايد وارد نماييد. براي مثال http://localhost:4326/
همچنين بايد دقت داشت كه در همين قسمت هيچكدام از debuggers ذيل گزينه‌ي use custom web server نبايد تيك خورده باشند (چون VS.NET دقيقا نمي‌داند كه بايد به كدام پروسه در ويندوز attach شود).
اكنون برنامه را در حالت ديباگ در VS.NET آغاز كنيد (بديهي است فرض بر اين است كه iisexpress.exe با تنظيمات ذكر شده بايد در حال اجرا باشد).
و ... حداقل مزيت آن بسيار سريع‌تر بودن اين روش نسبت به Cassini يا ASP.NET Development Server است.
تا اينجا فقط VS.NET به صورت خودكار مرورگر را باز كرده و سايت نمايش داده مي‌شود؛ اما اگر در قسمتي از كدهاي خود breakpoint قرار دهيم كار نمي‌كند. براي اين منظور بايد در حين اجراي برنامه، از منوي debug ، گزينه‌ي attach to process را انتخاب كرده و به iisexpress متصل شويد.

دستكاري mime types در IIS

چند روزي هست كه به دليل قطعي كابل، فايل‌هاي فلش سايت‌ها از كار افتاده!
فايل‌هاي فلش را بر اساس mime type آن‌ها فيلتر كرده‌اند يعني هر چه application/x-shockwave-flash كه از طرف وب سرور شما سرو شود فيلتر مي‌شود.
يك راه حل اين است كه پسوند تمام فايل‌هاي فلش را تغيير داد تا وب سرور ديگر اين mime type را از خودش بروز ندهد (در يك وب سرور هر mime type دقيقا به يك يا چند نوع پسوند فايل map شده). اين مورد نياز به اصلاح تمام صفحات سايت نيز خواهد داشت (علاوه بر تغيير پسوند فايل‌هاي موجود). خوشبختانه فلش پلير كاري به mime type يا حتي پسوند فايل، جهت نمايش آن ندارد.
راه حل ساده‌تر (بدون نياز به تغييري در فايل‌ها) هم اين است كه كمي تغييرات وب سرور خود را تغيير داد:

در IIS6 :

در IIS7 :

كلا mime type موجود را به براي مثال image/png تغيير دهيد تا قسمت‌هاي از كار افتاده سايت مجددا برقرار شود و آبروي كاري رفته مجددا به جوي بازگردد.

IIS7 و آپلود فايل‌هاي حجيم

با استفاده از IIS6 ويندوز سرور 2003 و تنظيمات ويژه در web.config يك برنامه ASP.Net، حداكثر مي‌توان يك فايل 2 گيگابايتي را آپلود كرد (جهت مصارف اينترانتي). براي مثال:

<system.web>
   <httpRuntime maxRequestLength="2097151" executionTimeout="900" />
</system.web>

2097151 كيلوبايت حداكثر مقداري است كه اينجا مي‌توان تنظيم كرد و بيش از اين با خطاي زير متوقف خواهيم شد:

Parser Error Message: The value for the property 'maxRequestLength' is not valid. The error is: The value must be inside the range 0-2097151.

اين محدوديت در IIS7 برطرف شده است كه تنظيمات آن در وب كانفيگ به صورت زير مي‌باشد:

<system.webServer>
   <security>
       <requestFiltering>
               <requestLimits maxAllowedContentLength="4294967295" />
            </requestFiltering>
   </security>
</system.webServer>

در اينجا maxAllowedContentLength بر حسب بايت است و نه همانند maxRequestLength برحسب كيلوبايت (كه در IIS7 هيچ تاثيري نخواهد داشت).
البته تنظيمات فوق در اينجا به پايان نمي‌رسند زيرا بر اساس تنظيمات امنيتي IIS7، كاربران مجاز به اعمال تنظيمات شخصي خود نيستند و خطاي زير را دريافت خواهند كرد:

The requested page cannot be accessed because the related configuration data for the page is invalid

و يا

The request filtering module is configured to deny a request that exceeds the request content length

براي اين منظور بايد دستور زير را با دسترسي مديريتي در خط فرمان اجرا نمود:
براي يك برنامه خاص:

%windir%\system32\inetsrv\appcmd set config "Default Web Site/<your app>" -section:requestFiltering -requestLimits.maxAllowedContentLength:4294967295

و يا براي تمام برنامه‌ها:

%windir%\system32\inetsrv\appcmd set config -section:requestFiltering -requestLimits.maxAllowedContentLength:4294967295

و يا فايل زير را يافته:

%windir%\System32\inetsrv\config\applicationHost.config

در آن سطر زير را

<section name="requestFiltering" overrideModeDefault="Deny" />

ويرايش كرده و مقدار overrideModeDefault آن‌را به Allow‌ تنظيم كرد:

<section name="requestFiltering" overrideModeDefault="Allow" />

مقدار پيش فرض maxRequestLength در IIS6 مساوي 4 مگابايت و مقدار پيش فرض maxAllowedContentLength در IIS7 مساوي 28.6MB‌ مي‌باشد. maxAllowedContentLength از نوع UINT32 است يعني حداكثر تا 4 گيگابايت را توسط آن مي‌توان مقدار دهي كرد. maxRequestLength از نوع Int32 است با حداكثر مقدار قابل تنظيم 2 گيگابايت.

تنظيمات امنيتي SMTP Server متعلق به IIS 6.0 جهت قرارگيري بر روي اينترنت

فرض كنيد يك سرور را بر روي اينترنت قرار داده‌ايد و از SMTP Server متعلق به IIS قصد داريد جهت ارسال ايميل توسط برنامه‌هاي خود استفاده نمائيد. در اين حالت مواردي را بايد رعايت نمود تا اين سرور تبديل به سرور رايگان ارسال spam توسط "دشمنان" نشود.

1- پورت پيش فرض را عوض كنيد
پورت پيش فرض اتصال به SMTP Server مساوي 25 است. از آنجائيكه به سادگي در برنامه‌هاي خود مي‌توان اين پورت را نيز تنظيم نمود، بهتر است به عنوان اولين قدم، اين پورت را تغيير داد. يك شماره پورت دلخواه خالي را يافته و بجاي 25 قرار دهيد. براي اين منظور مسير زير را طي كنيد:
بر روي Default SMTP Virtual Server در كنسول IIS كليك راست كرده و گزينه خواص را انتخاب كنيد. در برگه General روي دكمه Advanced كليك كرده و در صفحه باز شده سطر مربوط به پورت 25 را يافته، بر روي دكمه Edit كليك نموده و آن‌را به عددي ديگر تغيير دهيد.

2- دسترسي عموم را به سرور قطع كنيد!
متاسفانه تنظيمات پيش فرض SMTP Server متعلق به IIS در جهت قطع دسترسي "دشمنان" كاملا نادرست بوده و بر مبناي ايده حداقل دسترسي صورت نگرفته‌ است. اگر سرور را به اين حال رها كنيد فقط "دشمنان" را خوشحال كرده‌ايد.
براي قطع دسترسي دشمنان سه مرحله بايد صورت گيرد:
الف) در برگه Access مربوط به تنظيمات SMTP server ، روي دكمه relay كليك كرده، ابتدا تيك مربوط به Allow all computers which successfully authenticated to relay‌ را برداريد (اين مورد در يك شبكه داخلي حائز اهميت مي‌شود و ساير كامپيوترها را منع مي‌كند). سپس در قسمت بالاي صفحه گزينه only the list below را انتخاب كرده و IP آن‌را مساوي 127.0.0.1 وارد كنيد (يعني فقط اين كامپيوتر مجاز است كه از اين سرويس جهت ارسال ايميل استفاده كند؛ نه دشمنان خارجي).

ب) مورد الف را درباره‌ي قسمت مرتبط با دكمه connections نيز تكرار كنيد. (پيش فرض آن تمام عالم است!)

ج) در همين برگه‌ي Access بر روي دكمه Authentication كليك كرده و فقط تيك مربوط به integrated windows authentication را قرار دهيد. (هميشه تحت ويندوز اين روش authentication يكي از امن‌ترين‌ها است. همچنين در حالت قرارگيري سرور بر روي اينترنت سخت گيرانه‌ترين حالت ممكن را در اينجا انتخاب كرده‌ايم.)

خوب، با اين تنظيم قسمت (ج) ديگر برنامه‌ها با روش متداول قابل به ارسال ايميل نخواهند بود. يك يوزر معمولي local را به كامپيوتر افزوده (با حداقل دسترسي) و پسورد آن‌را در حالت never expires قرار دهيد. از اين يوزر ويندوزي جهت برقراري امكان اتصال به ميل سرور محلي در برنامه‌هاي خود استفاده خواهيم كرد (فرض بر اين است كه برنامه‌اي هم كه قرار است ايميل ارسال كند بر روي همان كامپيوتر سرور قرار دارد).

پس از اعمال اين تنظيمات بر روي دكمه apply كليك كنيد، تا تنظيمات اعمال شوند. يكبار نيز ميل سرور را استاپ و استارت كنيد.

3- تنظيمات ويژه برنامه‌ها براي ارسال ايميل:
در اين حالت برنامه‌هاي دات نت شما نياز به چهار تنظيم اضافه‌تر پيش از فراخواني تابع Send دارند:

MailMessage message = new MailMessage("from@site.com", strTo, subject, body)
{
     IsBodyHtml = true,
     BodyEncoding = Encoding.UTF8
};

SmtpClient client = new SmtpClient("127.0.0.1",portNumber);//portNumber is new
client.UseDefaultCredentials = false; //new
client.DeliveryMethod = SmtpDeliveryMethod.Network; //new
client.Credentials = new NetworkCredential("mail_user", "pass"); //new
client.Send(message);

همانطور كه ملاحظه مي‌كنيد بايد شماره پورت جديد را معرفي نمود، همچنين روش authentication و معرفي مشخصات يوزر ويندوزي كه اضافه كرديم را نيز نبايد فراموش كرد.

4- تمامي رخ‌دادهاي ميل سرور را ثبت كنيد.
براي اين منظور در برگه general ، تيك مربوط به enable logging را فعال كنيد. سپس بر روي دكمه خواص كنار آن كليك كرده و در صفحه باز شده به برگه extended properties مراجعه نموده و تمامي موارد را تيك بزنيد. به ازاي هر يك روز فعاليت سرور، يك فايل متني در مسير C:\WINDOWS\System32\LogFiles تشكيل خواهد شد.


سؤال چگونه تشخيص دهم كه ميل سرور من هك شده است يا خير؟!
اگر موارد فوق را رعايت نكنيد، در قسمت current sessions كنسول IIS مي‌توانيد "دشمنان" را مشاهده كنيد! همچنين مصرف CPU پروسه inetinfo.exe عملكرد سرور را مختل كرده، بعلاوه در مسير C:\Inetpub\mailroot\Queue احتمالا چند هزار ايميل درصف قرار گرفته شده براي ارسال را مي‌توانيد مشاهده كنيد! (همينطور در مسير C:\Inetpub\mailroot\Badmail نيز اين تعرض قابل مشاهده است)
اگر اين موارد را مشاهده كرديد، ابتدا سرور را استاپ كنيد، سپس محتويات پوشه‌هاي ياد شده را تخليه كرده و از مرحله يك فوق شروع به اعمال تنظيمات نمائيد.

ليست تازه‌هاي IIS 7.5

IIS 7.5 كه به همراه ويندوز سرور 2008 R2 ارائه مي‌شود شامل تازه‌هاي زير است:

• بيش از 50 مورد cmdlet جديد مخصوص Powershell جهت مديريت IIS
• افزونه‌هاي جديد مديريتي: Database Manager (مديريت اس كيوال سرور از درون IIS و كنسول آن)، Configuration Editor (توليد خودكار اسكريپت‌هاي مديريتي جهت اتوماسيون امور مرتبط)، IIS Reports و Request Filtering .
• پشتيباني از One-click publishing موجود در Visual Studio 10
• Web Deployment Tool يا همان MS Deploy سابق جهت مديريت بهتر برنامه‌هاي وب.
• امكان رديابي تغييرات در كانفيگ وب سرور
• گزارشگيري بهتر از وضعيت كارآيي سرور
• ساپورت دات نت جهت Server Core معرفي شده در ويندوز سرور 2008
• WebDav كه پيشتر به صورت يك افزونه‌ي آن معرفي شده بود، اكنون جزئي از IIS 7.5 است.
• يكپارچگي با URLScan 3.0 جهت بالا بردن امنيت وب سرور.
• FTP server services : با كنسول مديريتي IIS يكپارچه شده است با بهبودهايي در نحوه‌ي تنظيم كردن و رديابي آن.

جهت مطالعه بيشتر در مورد تازه‌هاي ويندوز سرور 2008 نگارش R2 مي‌توان به مقالات زير رجوع كرد:
Windows Server 2008 R2 new features - the complete list - Part 1: Virtualization
Windows Server 2008 R2 new features - the complete list - Part 2: Active Directory
Windows Server 2008 R2 new features - the complete list - Part 3: IIS 7.5 and Performance
Windows Server 2008 R2 new features - the complete list - Part 4: Administration

مشكل IIS6 و دريافت فايل‌هاي آفيس 2007

IIS6 فايل‌هايي را كه نشناسد، سرو نخواهد كرد. بنابراين اگر يكي از كاربران مثلا يك فايل docx آفيس 2007 را آپلود كرده باشد، به محض كليك بر روي لينك دريافت فايل، با خطاي زير متوقف خواهد شد:

HTTP Error 404 - File or directory not found

فايل بر روي سرور موجود است اما كاربر قادر به دريافت آن نيست.

براي شناساندن فرمت‌هاي جديد به IIS6 مي‌توان به يكي از دو روش زير عمل كرد:
الف) اضافه كردن mime-type جديد از طريق كنسول IIS
ب) ويرايش كردن فايل MetaBase.xml مربوط به IIS

در هر دو روش فوق نياز است تا با mime-type فايل‌هاي جديد آشنا بود. براي مثال ليست كامل mime-types مربوط به فايل‌هاي آفيس 2007 به صورت زير است:

.docm,application/vnd.ms-word.document.macroEnabled.12
.docx,application/vnd.openxmlformats-officedocument.wordprocessingml.document
.dotm,application/vnd.ms-word.template.macroEnabled.12
.dotx,application/vnd.openxmlformats-officedocument.wordprocessingml.template
.potm,application/vnd.ms-powerpoint.template.macroEnabled.12
.potx,application/vnd.openxmlformats-officedocument.presentationml.template
.ppam,application/vnd.ms-powerpoint.addin.macroEnabled.12
.ppsm,application/vnd.ms-powerpoint.slideshow.macroEnabled.12
.ppsx,application/vnd.openxmlformats-officedocument.presentationml.slideshow
.pptm,application/vnd.ms-powerpoint.presentation.macroEnabled.12
.pptx,application/vnd.openxmlformats-officedocument.presentationml.presentation
.xlam,application/vnd.ms-excel.addin.macroEnabled.12
.xlsb,application/vnd.ms-excel.sheet.binary.macroEnabled.12
.xlsm,application/vnd.ms-excel.sheet.macroEnabled.12
.xlsx,application/vnd.openxmlformats-officedocument.spreadsheetml.sheet
.xltm,application/vnd.ms-excel.template.macroEnabled.12
.xltx,application/vnd.openxmlformats-officedocument.spreadsheetml.template

روش ب)
ابتدا IIS6 را stop كنيد (در غير اينصورت قادر به ذخيره سازي تغييرات نخواهيد بود):

iisreset /stop

سپس فايل متابيس آن‌را در يك اديتور متني باز كنيد. اين فايل در آدرس زير قرار دارد:

C:\WINDOWS\system32\inetsrv\MetaBase.xml

تگ مربوط به IIsMimeMap را يافته و خطوط فوق را دقيقا به همين صورتيكه ملاحظه مي‌كنيد به آن اضافه نمائيد.

و در آخر IIS را راه اندازي كنيد:

iisreset /start

روش الف)
اين روش نيازي به stop و start وب سرور ندارد و به محض اضافه شدن، به صورت خودكار اعمال خواهد شد اما كمي طولاني‌تر است:
كنسول IIS را باز كنيد
بر روي web sites كليك راست كنيد. (منظور بالاترين سطح ممكن است)
گزينه properties‌ را انتخاب كرده و سپس به برگه http headers‌ مراجعه نمائيد.
در اينجا بر روي دكمه mime-types كليك كرده و در صفحه باز شده بايد تك تك موارد جديد را به صورت دستي وارد نمائيد (در اينجا نيازي به ذكر نقطه مربوط به پسوند فايل نيست)

لازم به ذكر است كه اين نوع mime-types به IIS7 اضافه شده‌اند.

وادار كردن IIS به استفاده از ASP.Net 3.5

همانطور كه مطلع هستيد در تنظيمات يك دايركتوري مجازي در IIS6 يا 5، حتي پس از نصب دات نت فريم ورك سه و نيم، گزينه انتخاب نگارش 3.5 ظاهر نمي‌شود و همان تنظيمات ASP.Net 2.0 كافي است (شكل زير) (دات نت 3 و سه و نيم را مي‌توان بعنوان افزونه‌هايي با مقياس سازماني (WF ، WCF و ...) براي دات نت 2 درنظر گرفت).

هنگام استفاده از VS.Net 2008 و تنظيم نوع پروژه به دات نت فريم ورك 3.5 ، به صورت خودكار تنظيمات لازم به وب كانفيگ برنامه جهت استفاده از كامپايلرهاي مربوطه نيز اضافه مي‌شوند كه شايد از نظر دور بمانند.
براي آزمايش اين مورد، فرض كنيد صفحه زير را بدون استفاده از code behind و VS.Net ايجاد كرده ايم (جهت آزمايش سريع يك قطعه كد Linq ).

<%@ Page Language="C#" %>

<%@ Import Namespace="System" %>
<%@ Import Namespace="System.Linq" %>

<form id="Form1" method="post" runat="server">
 <asp:GridView ID="GridView1" runat="server" />
</form> 


<script runat="server">
    protected void Page_Load(object sender, EventArgs e)
    {
      string[] cities = {
                          "London", "Amsterdam", "San Francisco", "Las Vegas",
                          "Boston", "Raleigh", "Chicago", "Charlestown",
                          "Helsinki", "Nice", "Dublin"
                        };

      GridView1.DataSource = from city in cities
                             where city.Length > 4
                             orderby city
                             select city.ToUpper();

      GridView1.DataBind();
    }
</script>

بلافاصله پس از اجرا با خطاي زير روبرو خواهيم شد.

اين قطعه كد چون از قابليت‌هاي كامپايلر جديد سي شارپ استفاده مي‌كند، با كامپايلر پيش فرض و تنظيم شده دات نت 2 كار نخواهد كرد و بايد براي رفع اين مشكل، فايل web.config جديدي را نيز به پوشه برنامه اضافه كنيم:

<?xml version="1.0"?>
<configuration>

<system.codedom>
  <compilers>
    <compiler language="c#;cs;csharp" extension=".cs" warningLevel="4" type="Microsoft.CSharp.CSharpCodeProvider, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
      <providerOption name="CompilerVersion" value="v3.5"/>
      <providerOption name="WarnAsError" value="false"/>
    </compiler>
  </compilers>
</system.codedom>

<system.web>
  <compilation defaultLanguage="c#">
    <assemblies>
      <add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
    </assemblies>
  </compilation>
</system.web>


</configuration>

در اينجا قيد اسمبلي System.Core ضروري است و همچنين نگارش كامپايلر نيز به صورت صريح قيد شده است تا IIS را وادار كند كه از قابليت‌هاي جديد دات نت فريم ورك استفاده نمايد.

همانطور كه ذكر شد اگر از VS.Net 2008 استفاده كنيد، هيچ وقت درگير اين مباحث نخواهيد شد و همه چيز از پيش تنظيم شده است.