به دلیل اینکه بسیار با این سوال مواجه شده‌ایم که استفاده از وب اپلیکیشن های متعدد در شیرپوینت خوب است یا بد، و چه بسا فارمهای عملیاتی شیرپوینتی که بدون در نظرگرفتن این مورد در حال استفاده گسترده میباشند، تصمیم به نوشتن این مقاله گرفتیم. پس با ما در ادامه مقاله مزایا و معایب احتمالی آن را مطالعه نمایید.
پیش از شروع دقت نمایید منظور ما از وب اپلیکیشن فقط وب اپلیکیشن‌هایی است که سایتهای فارم شما در آن قرار دارد و نه وب اپلیکیشن Central Administration که موقع نصب ایجاد و کانفیگ میشود. همچنین توجه نمایید که این موارد شامل تمامی ورژنهای شیرپوینت میشود.
مزایای استفاده از وب اپلیکیشن های متعدد در شیرپوینت
استفاده از متدهای مختلف اهراز هویت (Authentication)
متد اهرازهویت در فارم شیرپوینت میتواند به ازای هر وب اپلیکیشن متفاوت باشد که این خود کاربردهای فراوانی خواهد داشت. برای مثال فرض کنید سایتهایی از کسب و کار را باید علاوه بر پرسنل داخلی ( که برای مثال با اکانتهای اکتیودایرکتوری خود لاگین میکنند) نمایندگان سازمان نیز بتوانند لاگین نمایند و در آن سایتها تعامل کنند (فرم پرکنند، سند بارگزاری نمایند و…). پس این سایتها را میتوان با یک وب اپلیکیشن مجزا نمود تا مطمئن بود پرسنل خارجی قادر نخواهند بود به سایتهای دیگر دسترسی پیدا کنند.
پابلیش نمودن سایتها
3برای مثال فرض کنید سایتهای شما در سازمان فقط از داخل با آدرسی داخلی مانند http://portal.company.com قابل مشاهده است و اکنون میخواهید سایتهایی را در شبکه خارجی خود (مانند اینترنت) نیز پابلیش کنید یکی از راهکارهای این موضوع، ایجاد وب اپلیکیشنی مخصوص برای این سایتها و سپس پابلیش نمودن آدرس این وب اپلیکیشن است برای مثال سایتهای https://company.com و https://company.com/project سایتهایی هستند که با استفاده این وب اپلیکیشن(https://company.com) پابلیش شده اند. مثالی دیگر از این میتوان به پابلیش نمودن سایتهای شخصی افراد جهت استفاده در OneDrive For Business اشاره نمود. (نحوه استفاده از OneDrive For Business در شیرپوینت)
معایب استفاده از وب اپلیکیشن های متعدد در شیرپوینت
سربار timer job های شیرپوینت به ازای هر وب اپلیکیشن جدید
به ازای هر وب اپلیکیشن جدید که در شیرپوینت ایجاد میکنید شیرپوینت تعداد قابل توجهی جاب برای آن وب اپلیکیشن ایجاد میکند که در فواصل زمانی مختلف اجرا خواهد شد. برای مثال تصویر زیر تعدادی از آنها را نمایش میدهد
حتی با توجه به اینکه برخی از این جابها روی سرورها بر حسب نقش سرور (سرویسهای هر سرور) پخش میشود ، باز حجم ریسورس قابل توجهی اشغال خواهد نمود.
سربار هر وب اپلیکیشن در IIS
به دلیل تبدیل هر Application Pool شیرپوینت به یک IIS Application Pool و همچنین اختصاص تقریبا یکنواخت ریسورس بین وب اپلیکیشنهای داخل یک IIS Application Pool یا حتی IIS Application Pool های مجزا، نمیتوان اهمیت یک وب اپلیکیشن یا یک سایت پر بازدیدتر را بیشتر نمود. برای مثال فرض کنید سایتی با استفاده کمتر را تبدیل به یک وب اپلیکیشن نمودید و سایتهای متعدد و پر اهمیت نیز در یک وب اپلیکیشن دیگر، به دلیل تقسیم ناعادلانه ریسورس بین این وب اپلیکیشن برای ارتقاء پرفورمنس سایت پراهمیت سازمان باید به دیگر سایتهای بی اهمیت نیز ریسورس اضافه کنید!
برای درک عمیق تر این موضوع و نتایج تستهای گرفته شده برای این واقعیت میتوانید این وبلاگ را مشاهده نمایید.
نتیجه گیری
با توجه به مزایا و معایب گفته شده در بالا و همچنین الزامات داخلی خود تا حد امکان از تقسیم نمودن سایتها در وب اپلیکیشنهای مجزا خودداری نمایید و تمامی سایتهای خود را در یک وب اپلیکیشن حفظ کنید.
همچنین در صورت نیاز به تخصیص آدرسهای متنوع به سایتهای شیرپوینت خود به جای استفاده از وب اپلیکیشنهای مجزا از Host Named Site Collection استفاده نمایید.
مطالب مرتبط
