مفهوم ایزوله سازی محاسبات به این معناست که برای مثال کدهای وب سایت مشتری اول در یک فرایند اجرا محاسبه شده و کدهای وب سایت مشتری دوم نیز به صورت کاملا جداگانه در فرایندی مستقل اجرا می گردند.
وب سرور IIS به طور معمول این توانایی را دارد تا تمامی فرمت های استاندارد مانند HTML استاتیک و … را به راحتی پردازش نماید. اگر بازدیدکننده ای به وب سایت شما رفته و قصد مشاهده فایل index.html را داشته باشد، هسته مرکزی وب سرور IIS فایل مورد نیاز را از حافظه بازیابی کرده و پس از پردازش آن، نتیجه را به مرورگر بازدیدکننده ارسال می کند. اما وب سرور برای پردازش کدهای داینامیک و یا اسکریپت های فایل بیس مانند ASP و یا ASP.Net، درخواست ها را به یک Application Pool ارجاع می دهد. Application Pool با روند پردازشی مستقل و جداگانه، میزبان مناسبی برای پردازش این نوع کدهای داینامیک می باشد. با استفاده از این قابلیت شرکت های ارایه دهنده خدمات میزبانی اشتراکی می توانند با در نظر گرفتن Application Pool های اختصاصی برای هر وب سایت، تدبیری بیاندیشند تا کدهای هر وب سایت با استفاده از شناسه ای منحصربفرد از یکدیگر جدا شده و به صورت مستقل اجرا می شوند.
تصویر فوق سناریویی بدین صورت را به تصویر می کشد که در آن درخواست هایی که برای DomainX.com ارسال می گردند، مستقیما بر عهده Application pool قرار میگیرد که مختص به تنها DomainX.com می باشد. این قابلیت برتری های مهمی مانند پایداری بیشتر و امنیت بالا را برای کل سیستم به ارمغان می آورد که در ادامه توضیحات بیشتری در این زمینه ارایه شده است :
– در صورتی که وب سایت DomainX.com با کدهای ASP نامناسب و سنگینی نوشته شده باشد که باعث هنگ کردن مراحل پردازش گردند، این مشکل تنها در حیطه DomainX.com رخ خواهد داد و به هیچ وجه بر روی روند محاسبات DomainY.com تاثیری نمی گذارد. زیرا کدهای DomainY.com در Application pool جداگانه و مستقل خود اجرا می شوند.
– سطح دسترسی های هر وب سایت فقط مربوط به کاربران خود خواهد بود، بنابراین محاسبات انجام شده ای که تحت Application Pool سرویس DomainX.com رخ داده اند، بر روی فایلهای DomainY.com اعمال نخواهند شد.
– اگر وب سایت DomainZ.com اقدام به انجام عملیات مخرب یا غیر مجازی نماید، تمامی کدهایش تحت شناسه منحصر بفرد کاربری آن اجرا می گردند. این امر به شرکت های هاستینگ کمک می کند تا افراد خاطی و مسئول را به سرعت شناسایی نمایند.
بسیاری از افراد اکثرا در تشخیص User ID که کد های ASP خود تحت آن ها به اجرا در می آیند، دچار اشتباه می شوند. این موضوع به دلیل برخی وجود سوتدبیر هایی از مقالات درج شده در سایت مایکروسافت می باشد. مقالات ارایه شده توسط مایکروسافت معمولا شامل مطالب مفید و دقیقی می باشند، اما اکثر آن ها در مورد زمانی است که وب سایت شما در یک سرور اختصاصی میزبانی شده است و توضیحی در مورد نحوه نام گذاری User ID های Application Pool در میزبانی های اشتراکی ارایه نشده است.
در وب سرورهای ویندوزهای ۲۰۰۳ و ۲۰۰۸ برای هر وب سایت ایجاد شده به صورت پیش فرض یک Application Pool اختصاصی ایجاد می شود و این Application Pool پیش فرض تحت کاربری پیش فرض NETWORK SERVICE اجرا می گردد (این کاربر در نسخه های قبلی IIS به نام ASPNET بود). در صورتی که تنظیمات به همین صورت پیش فرض رها شوند، کد تمامی وب سایت ها، تحت نام کاربری NETWORK SERVICE به اجرا در آمده و در نتیجه هر کاربر می تواند به فایل های سایر وب سایت ها دسترسی داشته باشد. این امر موجب کاهش ضریب امنیتی و همچنین پایداری سرویس ها می گردد.