بهینه‌سازی GIS سرویس‌ها

بهینه‌سازی GIS سرویس‌ها-موسسه چشم انداز-آموزش کاربردی GIS و RS

با مهارت‌هایی که در فصل‌های قبلی کسب کردید، سرویس‌هایی که طراحی کردید را ایجاد و منتشر کردید. همچنین کدی نوشتید تا کاربران از سرویس‌هایتان استفاده کنند. زمان مدیریت و اجرای کارآمد و مؤثر سرویس‌ها فرا رسیده است. GIS سرویس‌ها تنها چند مگابایت از حافظه را برای شروع اجرا می‌گیرند و همچنان که مصرفشان بالا می‌رود، GIS سرور برای این سرویس‌ها بیشتر و بیشتر حافظه می‌گیرد. با توجه به محدودیت حافظه و CPU، باید منابع GIS سرور را به سرویس‌هایی که واقعاً به آن‌ها نیاز دارند، تخصیص دهیم. در این بخش با یادگیری سه تکنیک در سرور، نتایج بهینه‌ای به دست می‌آوریم. اولین تکنیک pooling نام دارد. در این تکنیک نمونه‌هایی از سرویس‌های در حال اجرا در قالب یک ابزار گروه‌بندی می‌شوند. با این تکنیک هر نمونه می‌تواند طی چندین زمان، مجدداً استفاده شود. بدین ترتیب هر نمونه به کاربران بیشتری سرویس می‌دهد. دومین تکنیک فرآیند جداسازی- process isolation است. این تکنیک نمونه‌ها را در یک یا چند فرآیند گروه‌بندی می‌کند تا منابع بین این فرآیندها به اشتراک گذاشته شود. سومین تکنیک Caching است که در بعضی منابع به‌عنوان کاشه کردن آمده است. در این تکنیک به‌جای اینکه داده‌ها هر بار از روی پایگاه داده صدا زده شوند، داده‌ها روی GIS سرور ذخیره می‌شوند. بدین ترتیب هنگام صدا زدن و بارگذاری داده در مصرف منابع صرفه جویی می‌شود. با استفاده از این تکنیک‌ها بار روی سرویس‌ها را به‌صورت کارآمد و مؤثر، متوازن و برابر می‌کنید.

نمونه‌ی GIS سرویس

هر سرویسی که روی ArcGIS for Server منتشر می‌کنید، سرانجام درون یک یا چند نمونه‌ی در حال اجرا روی GIS سرور گردآوری می‌شوند. نمونه‌ها به‌طور مساوی در تمام GIS سرورها تقسیم شده‌اند. هنگام انتشارهر سرویس، تعداد نمونه‌های هر GIS سرور قابل تنظیم است. برای مدیریت مؤثر و کارآمد این نمونه‌های در حال اجرا، Esri تکنیک‌های جدیدی که در این بخش یاد می‌گیرید را ارائه کرده است.

تکنیک Pooling

سرویس‌های GIS برای استفاده در پلتفرم‌های مختلف به کار می‌روند. طیف وسیعی از مشتریان از نرم‌افزارهای مختلف می‌توانند از این سرویس‌ها استفاده می‌کنند. در مدل یک به یک برای هر نمونه یک اتصال جدید تخصیص داده می‌شود. اگر برای هر اتصال جدید از یک نمونه‌ی جدید استفاده شود، مطمئناً راه مناسبی نیست زیرا سرویس‌های GIS وابستگی زیادی به هم دارند و تمایل زیادی برای مصرف بالای حافظه و پردازشگر دارند. پس به مدل دیگری نیاز داریم تا به سرور متصل شود تا اتصالات بیشتری را با منابع محدود و قابل دسترس مدیریت کند. بدین ترتیب Esri اولین بار در سال 2007 تکنیک Pooling را معرفی کرد. در این مدل هر اتصال از یک نمونه سرویس GIS برای یک مدت زمانی مشخص استفاده می‌کند. این مدت زمانی از میلی ثانیه تا چند دقیقه قابل تنظیم است. هر نمونه در یک زمان به یک اتصال سرویس می‌دهد. مثلاً اگر یک کاربر در حال استفاده از ArcMap جهت بزرگ نمائی محدوده‌ی خاصی از نقشه‌ی موجود در یک GIS سرویس باشد، درخواست محدوده‌ی جدید به وب سرور فرستاده می‌شود. وب سرور درخواست را به یکی از GIS سرورها می‌فرستد. GIS سرور از یک نمونه‌ی آزاد و بیکار برای اجرای درخواست استفاده می‌کند. وابسته به درخواست، اجرای درخواست از چندمیلی ثانیه تا چند دقیقه طول می‌کشد و در طی این زمان به نمونه یک برچسب با عنوان ” مشغول” زده می‌شود. وقتی اجرا کامل می‌شود، نمونه آزاد می‌شود و GIS سرور نتایج را برمی‌گرداند. چندین اتصال از یک گروه شامل چند نمونه تغذیه می‌کند. با استفاده از این تکنیک یک نمونه‌ی منفرد می‌تواند به 10 اتصال و یا حتی بیشتر سرویس دهد.

ساختمان Pooling

برای توضیح بهتر Pooling از یک مثال شروع می‌کنیم. یک سرویس نقشه‌ای برق روی GIS-SERVER01 در حال اجرا است. با استفاده از نمودار زیر این سرویس را نمایش می‌دهیم. همانطور که می‌بینید در ابتدا یک نمونه در حال اجرا است:

فرض کنید R1، درخواست بزرگنمائی محدوده‌ای از نقشه برای مشاهده‌ی کابل‌های برق است. این درخواست جهت اجرا به GIS-SERVER01 ارسال می‌شود.

GIS-SERVER01 ابتدا یک نمونه‌ی موردی آزاد (در حال اجرای یک درخواست نیست) را پیدا می‌کند و درخواست R1 را به این نمونه جهت اجرا می‌فرستد.

درخواست R1 با موفقیت اجرا می‌شود و نمونه برای استفاده‌ی مجدد آزاد می‌شود.GIS-SERVER01 مجدداً دو درخواست دیگر R2 و R3 را می‌گیرد.R2 و R3 درخواست‌های پیمایش شبکه هستند که زمان اجرای طولانی دارند. نمونه‌ای که درخواست R1 را اجرا کرده است، الآن آزاد است و هیچ نمونه‌ی قابل دسترس جدید دیگری وجود ندارد. از آنجا که فضایی برای ایجاد نمونه‌های جدید وجود دارد، سرور درخواست R2 را به اولین نمونه تخصیص می‌دهد و یک نمونه‌ی جدید دیگری ایجاد می‌کند و درخواست R3 را به آن تخصیص می‌دهد.

در این حین، درخواست‌های بیشتری به نام R4 و R5 در یک زمان می‌رسند.R4 و R5 درخواست‌های پیمایش شبکه هستند و R6 درخواست عملیات بزرگ نمایی است. در حال حاضر هیچ نمونه‌ی آزاد قابل دسترسی وجود ندارد. دو نمونه‌ی قابل دسترس در حال اجرای درخواست‌های R2 و R3 هستند؛ بنابراین سرور دو نمونه‌ی دیگر ایجاد می‌کند. هر GIS سرویس تعداد نمونه‌ی مشخص شده‌ای را می‌تواند بپذیرد. در حال حاضر این GIS سرویس حداکثر تعداد نمونه‌ را گرفته است. متأسفانه سرور نمی‌تواند تعداد درخواست‌ها و زمان اجرای این درخواست‌ها را پیش‌بینی کند. درخواست‌های R4 و R5 نمونه‌های جدیدی را می‌گیرند و درخواست R6 که یک عملیات بزرگ نمائی ساده است، منتظر می‌ماند تا یک نمونه آزاد و قابل دسترس شود. حداقل و حداکثر تعداد نمونه‌ها هنگام انتشار GIS سرویس به‌صورت پارامتر قابل تنظیم است.

Esri تا نسخه‌ی 10.1 رویکرد Pooling را به‌صورت اختیاری قرار داده بود. سپس درنتیجه‌ی تکنیک مدیریت منابع این رویکرد را اجباری کرد. Pooling تاریخچه‌ی اتصالات را به خاطر نمی‌آورد. بدین معنی که هر زمان که یک درخواست می‌رسد، یک اتصال pooling می‌تواند از نمونه‌های مختلفی استفاده کند. به‌عنوان یک مثال دیگر، ویرایش نمی‌تواند پیمایش‌ها و عملیات ویرایش یا فرآیند ویرایش تحت وب را نگهدای کند؛ بنابراین نمی‌توان از عملیات undo یا redo استفاده کرد، زیرا هیچ تاریخچه و فایل Log ای که شامل عملیات و فرآیندهای ویرایش باشد، وجود ندارد. Esri گزینه‌ی ویرایش را روی سرویس‌های Pooling از شروع نسخه‌ی 10.1 فعال کرد.

پیکربندی سرویس‌های pooled

در این بخش پارامترهای pooling را برای بعضی از سرویس‌هایی که در فصل‌های قبلی منتشر کردید تنظیم و پیکربندی خواهید کرد. این پارامترها بر اساس نوع سرویس باید به دقت انتخاب شوند. مثلاً اگر از یک سرویس زیاد استفاده نمی‌شود، می‌توانید تعداد نمونه‌های این سرویس را کم کنید. یا اگر یک سرویس به کرات استفاده می‌شود، می‌توانید تعداد نمونه‌های این سرویس را افزایش دهید. سرویس Parcels را که قبلاً منتشر کرده‌اید در نظر بگیرید. در این سرویس عملیات زیادی روی پارسل‌ها انجام نمی‌شد و فقط امکان Zoom و Pan را دارد. این سرویس از نوع ساده است؛ اما سرویس Electricity امکان اجرای تجزیه و تحلیل و عملیات پیچیده را دارد. سرویس Electricity نمونه‌ای از سرویس rich است. به سرویس‌هائی مانند Electricity که امکان اجرای تجزیه و تحلیل و عملیات پیچیده‌ی دیگر را دارند، اصطلاحاً سرویس rich می‌گویند. می‌خواهیم سرویس Parcels را ویرایش و پارامترهای pooling را برای این سرویس تنظیم کنیم.

ArcGIS Server Manager را بازکنید و روی سرویس Parcels کلیک کنید. از سمت چپ صفحه روی pooling کلیک کنید. فیلد Minimum number ofinstances per machine: تعداد نمونه‌هایی که یک سرویس باید با این تعداد شروع به اجرا کند را مشخص می‌کند. مقدار پیش‌فرض این فیلد یک است و بدین معنی است که هر زمانی که این سرویس اجرا شود، یک نمونه‌ی منفرد اجرا خواهد شد. عبارت “per machine” که در این فیلد وجود دارد بدین معنی است که این گزینه به هر GIS سرور اعمال خواهد شد. دو GIS سرور GIS-SERVER01 و GIS-SERVER02 را در نظر بگیرید که روی سایت سرور پیکربندی‌شده‌اند و می‌خواهیم روی هر سرور یک نمونه منفرد داشته باشیم. فیلد Minimum numberof instances per machine را به مقدار 2 تنظیم کنید. درنتیجه 4 نمونه ایجاد می‌شود. اگر در داده‌های سرویس Parcels به ندرت جستجو انجام می‌شود، نیازی نیست که در همان آغاز اجرای این سرویس، یک نمونه اشغال شود. پس بهتر است برای این سرویس این فیلد را با مقدار 0 تنظیم کنید. هر زمان کسی درخواستی به این سرویس بفرستد، یک نمونه‌ی جدید ایجاد خواهد شد و درخواست اجرا می‌شود.

دومین پارامتر، فیلد Maximum number of instances per machine حداکثر تعداد نمونه‌های یک GIS سرویس را مشخص می‌کند. مثلاً اگر این فیلد را با مقدار 10 تنظیم کرده باشید و همه‌ی 10 نمونه‌ی این سرویس در حال اجرا باشند و کاربر یک درخواست به این سرویس بفرستد، کاربر باید منتظر شود تا یک نمونه آزاد شود و هیچ نمونه‌ی جدیدی ایجاد نخواهد شد؛ زیرا با توجه به مقدار این فیلد، حداکثر 10 نمونه برای این سرویس ایجاد شده است. در این سرویس می‌توانید مقدار این فیلد را با 1 تنظیم کنید زیرا هیچ عملیات خاص و پیچیده‌ای در این سرویس وجود ندارد. زمان انتظار کاربر نیز با فیلد The maximum time a client will wait to get a service قابل تنظیم است. واحد این فیلد بر اساس دقیقه است. از آنجا که عملیاتی مانند Zoom و Pan بیشتر از چندثانیه طول نمی‌کشد، بهتر است مقدار این پارامتر را برای این سرویس 15 ثانیه تعیین کنید. اگر زمان اجرای کامل یک درخواست بیشتر از 15 ثانیه شود، درخواست نادیده گرفته شده و لغو می‌شود؛ و این درخواست دوباره باید ارسال شود. فیلد The maximum time a client can usea service حداکثر زمانی که کاربر می‌تواند از یک نمونه استفاده کند را مشخص می‌کند. در سرویس Parcels عملیات ساده‌ای انجام می‌شود و بیشتر از 5 ثانیه هم طول نمی‌کشند. مقدار پیش‌فرض این فیلد 600 ثانیه است. البته این مقدار پیش‌فرض با توجه به نسخه‌ی سرور ممکن است متفاوت باشد. اگر یک درخواست بیشتر از 600 ثانیه یک نمونه را مشغول می‌کند، ممکن است در شبکه مشکلی پیش آمده و یا یک حلقه‌ی نامحدود به وجود آمده باشد و مواردی از این قبیل محتمل است. پس سرور می‌تواند این درخواست را لغو کند و نمونه را برای درخواست‌های بعدی آزاد کند.

اگر یک سرویس برای مدت طولانی مورداستفاده قرار نمی‌گیرد باید از حافظه حذف شوند تا فضا برای سرویس‌های دیگر آزاد شود. به ندرت پیش می‌آید که کاربر سرویس Parcels را جهت استفاده صدا بزند. این سرویس حافظه‌ی زیادی را مصرف می‌کند؛ بنابراین در فیلد The maximum time an idle instance can be kept running مقدار 1 دقیقه را تنظیم می‌کنیم.

قبل از تنظیم و پیکربندی پارامترهای Pooling باید نوع سرویس خود را از لحاظ ساده یا rich بودن مشخص کنید.

حال می‌خواهیم پارامترهای Pooling را برای سرویس Electricity تنظیم کنیم. این سرویس را برای یک نوع درخواست صدا می‌زنیم که درخواست زمان زیادی برای اجرا می‌گیرد. این درخواست‌ها علاوه بر عمل Zoom و Pan شامل عملیاتی مانند ترسیم، تجزیه و تحلیل شبکه و بسیاری عملیات پیچیده وپیشرفته‌ی دیگری هستند؛ بنابراین نمونه‌ها در هر زمان باید قابل دسترس باشند. همانطور که در تصویر زیر می‌بینید، مقدار حداقل و حداکثر نمونه‌ها را تنظیم کردیم. همچنین مقدار زمان idle (آخرین فیلد) را یک ساعت مشخص کردیم که این سرویس در صورتی که تا یک ساعت استفاده نشود، از حافظه پاک می‌شود. تصویر زیر تنظیم پارامترهای Pooling این سرویس را مشخص می‌کند.

اگر از نصب production استفاده می‌کنید، از تنظیمات پیش‌فرض پارامترهای Pooling به هیچوجه استفاده نکنید. ابتدا نوع سرویس را باید تشخیص دهید و سپس پارامترها را تنظیم کنید.

برگرفته از کتاب نصب، اجرا و مدیریت Arc GIS for server

نویسنده: دکتر محمد بافقی زاده

نشر: انتشارات اکادمیک