کارایی، سرعت و مقیاس پذیری را نمی توان در معماری پورتال ها نادیده گرفت. طراحی یک پورتال موثر در مقیاس کوچک می تواند با توسعه سازمان، کاربردها، افزایش حجم اطلاعات ساخت یافته ، کاربران و … تبدیل به معضل اصلی فناوری سازمان شود. مشکلی که چنانچه مورد ارزیابی و تحلیل صحیح و به موقع قرارنگیرد، در مورد شیرپوینت به سرعت بروز می نماید.
معماری پورتال شیرپوینت در بخشهای مختلف مستعد بروز این چنین مشکلاتی است. پورتال شیرپوینت برای هر کاربرد ذخیره سازی شامل محتوا و مستندات ، وابستگی شدیدی به سرویس دهنده پایگاه داده دارد. در واقع محتوای پویای کلیه صفحات، داده های به اشتراک گذاشته شده توسط کاربران و .. همگی در بانک اطلاعاتی ذخیره می شوند. به این ترتیب مکانیزم های دسترسی به پایگاه داده و بازیابی اطلاعات با روند رو به رشد حجم داده ها ، با سرعت به گلوگاه سیستم بدل می شوند. زمان پاسخگویی سرویس دهنده به درخواست ها بصورت غیرقابل تخمین و تحملی افزایش یافته و مقیاس پذیری زیرساخت در سازمان بدون اینکه بتوان با افزایش توان سخت افزاری راهکار مناسب و بلند مدتی را برای آن ارایه داد، زیر سوال می رود.
می توان وضعیت موجود را به این شکل تصور کرد: سخت افزار 64 بیتی و پرهزینه شیرپوینت (که از ویرایش 2010 این محصول بعنوان پیش نیاز آن مطرح شده است)، که در ابتدا نیازمندیهای محیط اجرای پورتال را برآورده می کرد، نیز دیگر جوابگوی حجم درخواست ها و پردازش ها نیست، در حالیکه کارایی پائین پورتال شیرپوینت، مشکلات عدیده ای را ایجاد کرده است. یکی از بزرگترین مشکلات پیش روی متخصصان در مسیر بهینه سازی کارایی پورتال شیرپوینت ، تعدد و پیچیدگی جزئیات پیکربندی های سرویسهای متعددی است که مورد استفاده شیرپوینت قرار گرفته اند. باید در نظرگرفت علاوه بر وابستگی پورتال شیرپوینت به معماری دات نت، سرویس دهنده SQLو وب سرور ، فاکتورهای موثر دیگری همچون احراز هویت یکپارچه از طریق Active Directory، ترافیک و پهنای باند شبکه و نهایتا ساختار فیزیکی سخت افزار وجود دارد. مشکل اینجا است که با توجه به پیچیدگی معماری نمی توان براحتی به ریشه مشکلات پی برد.
همانطور که اشاره شد شیرپوینت کلیه داده ها در بانک اطلاعاتی رابطه ای خود ذخیره سازی می کند. همین مسئله از مهمترین دلایل افت کارایی تلقی می شود. شیرپوینت جهت ذخیره سازی کلیه داده های کاربران از ساختار فیلدهای باینری(BLOB) استفاده می کند. متاسفانه سرویس دهنده های بانک های اطلاعاتی رابطه ای جهت پردازش و مدیریت حجم بالای اطلاعات باینری بهینه سازی نشده اند. این داده های ساختارنیافته، درصد عظیمی از منابع اطلاعاتی پورتال را به خود تخصیص داده اند از جمله مستندات، محتوای صفحات، اطلاعات نشست کاربران و اطلاعات حفظ وضعیت صفحات وب . با توجه به تعاملات بالای شیرپوینت با مستندات، که البته در پایگاه داده نگهداری می شوند، روالهای شاخص گذاری داده ها به سمت بانک اطلاعاتی سوق داده شده و منجر به افزایش حجم بارکاری در لایه بانک اطلاعاتی می شود. ضمن اینکه با توجه به ماهیت ناشناخته و غیرشاخص پذیر داده های با قالب BLOB، نمی توان براحتی رویه های حافظه نهان (Cache) را مدیریت کرد. جهت رفع این مشکل اغلب پیشنهاد می شود که این اقلام اطلاعاتی به خارج از ساختار بانک اطلاعاتی و به سطح سیستم فایل حتی بر روی سرور مستقل مشابه سرویس دهنده SAN انتقال داده شود. ولی مشکلات به همین جا ختم نمی شود. نخست اینکه وابستگی شیرپوینت به بانک اطلاعاتی، مشکل بروزرسانی اطلاعات را پدید می آورد. در واقع بایستی پس از انتقال داده به سیستم فایل، راهکاری هم جهت تغییر رفتار پیش فرض شیرپوینت ارایه داد. متاسفانه هیچ راهکار قابل پیکربندی در شیرپوینت برای این منظور در نظر گرفته نشده است. توسعه دهندگان سازمان بایستی خود جهت پیاده سازی ماژول های مورد نظر به منظور تعامل با مخزن ذخیره سازی خارجی اطلاعات باینری یا EBS اقدام نمایند که البته نیازمند درک درستی از رابطهای نرم افزاری ارایه شده از سوی مایکروسافت می باشد. همچنین می توان این ماژول را از طریق ارایه دهندگان محصول مربوطه تهیه کرد که البته هزینه های خود را بهمراه خواهد داشت. ضمن اینکه جای این سوال باقی می ماند که چنانچه بایستی جهت استفاده از شیرپوینت در محیط های واقعی دست به چنین تغییراتی زد و چرا از ابتدا این نکات در طراحی شیرپوینت در نظر گرفته نشده است؟ حتی در صورت اعمال این چنین تغییرات، نمی توان عواقب احتمالی آن را نادیده گرفت. بعنوان مثال، در وضعیت جدید به ازای هر تغییر صورت گرفته، یک نسخه از مستند مربوطه در مخزن ایجاد شده و نسخه های قبلی کماکان باقی خواهند ماند. در اینصورت بایستی مکانیزم کنترل نسخه ها و ارجاعات نامعتبر را بازبینی مجدد نمود. مشکل دیگر، مربوط به مکانیزم های داخلی پورتال شیرپوینت جهت بازیابی داده ها از جداول بانک اطلاعاتی در لیست ها و پرس و جوهایی است که بصورت خودکار از طریق رابط CQWP اجرا می شود. به طور پیش فرض این پرس و جوها بدون توجه به محدودیت های تعیین شده در تنظیمات لیست، حجم داده ای به مراتب بزرگتری را بازیابی می کنند. ضمن اینکه با توجه به ساختار ناشناخته مدل داده ای، نمی توان چندان به تاثیر شاخص گذاری در فیلدهای جداول مرتبط امیدوار بود. شیرپوینت جهت ذخیره سازی دادهای مربوط به وب پارتها،لیست ها، صفحات و … از یک جدول واحد به نام allUserData استفاده می نماید. در واقع در طراحی مدل داده ای، کمترین میزان نرمال سازی منظور شده است. در محیط واقعی با تعداد کاربران زیاد، عدم بهینه سازی پرس و جوهای تولید شده در لیست ها، حجم بار ایجاد شده در سطح بانک اطلاعاتی را به شدت افزایش داده و منجر به کاهش کارایی در مکانیزم هایی همچون شاخص گذاری، جستجو و زمان پاسخگویی می شود. متاسفانه هر چه ساختار درختی محتوا در پورتال توسعه می یابد، وضعیت بغرنج تر می شود. از جمله علل دیگر کارایی پائین را می توان در ساختار ارتباطی شبکه، نیازشیرپوینت به پهنای باند بالا جهت دسترسی به سرویسهایی همچون ActiveDirectory جهت تصدیق هویت جستجو کرد. ساختار مدیریت ارتباط شبکه در پشته پروتکلی NTLM کارایی کافی را جهت پاسخگویی به حجم درخواستهای پورتال شیرپوینت ندارد و در این زمینه پیشنهاد می شود از مکانیزم های مشابه kerberos جهت تصدیق هویت استفاده شود. همچنین بررسی نشان می دهد، پیاده سازی مکانیزم های دسترسی به بانک اطلاعاتی محتوا در شیرپوینت از طریق واسط COM در سطح اشیای کلیدی SPSite و SPWeb، پدیده نشتی حافظه را به بار آورده است. توسعه دهندگان بصورت حریصانه ای از این شی، جهت دسترسی و بازیابی اطلاعات محتوایی پورتال در بخشهای مختلف بهره برداری می کنند، بدون توجه به این امر که فقدان روالهای مدیریت حافظه خودکار موسوم به GC ، منجر به نشتی حافظه مستمر در سرویس دهنده IIS می شود. اشتباه بزرگ اغلب سازمانهایی که از پورتال شیرپوینت استفاده می کنند در یک مسئله است : آنها بانک اطلاعاتی پورتال شیرپوینت را انعطاف پذیرترین طراحی ممکن جهت انجام پردازشهای سنگین برخط فرض می کنند. یعنی تصور می کنند بدون وجود هر گونه نگرانی نسبت به جامعیت مدل شماتیک پایگاه داده و یا بروزرسانی منطق روالهای دسترسی به داده ها، قادر خواهند بود ساختار بانک اطلاعاتی آن را برای کاربردهای خاص خود سفارشی سازی نمایند. اما متاسفانه بانک اطلاعاتی شیرپوینت با توجه به موارد اشاره شده، از سطح نرمال سازی مطلوبی برخوردار نبوده و بعنوان یک مدل رابطه ای جهت انجام پردازش های سنگین داده ای بهینه سازی نشده است. سازمانهای بایستی جهت برآورده ساختن نیازهای خود، دست به طراحی و پیاده سازی بانک اطلاعاتی خود زده و شیرپوینت را تنها برای کاربردهای از پیش تعریف شده آن مورد بهره برداری قرار دهند. در کل بایستی گفت، بهینه سازی کارایی شیرپوینت همانند بسیاری دیگر از بخشهای آن، فرآیندی پیچیده، نفس گیر و کاملا پرهزینه است. شناسایی عمیق مدل منطقی، جزئیات طراحی و معماری و مکانیزم های تعاملی لایه های مختلف سرویس های شیرپوینت جزو ملزومات این امر به شمار می آیند.
نویسنده: مهندس آرش رامز
دیدگاه خود را بنویسید