6. کارایی نرم افزار های تجاری


بسیاری از تصمیماتی که درباره معماری گرفته می‌‌شود بخاطر کارایی سیستم است. در بیشتر موارد در مسائل مربوط به کارایی سیستم، بهتر است ابتدا سیستم راه‌‌اندازی شود و از آن اجرا گرفته شود سپس ارزیابی انجام شود، بعد از این از یک پروسه بهینه‌‌سازی منظم براساس این اندازه‌‌گیری‌‌ها استفاده کنیم. تعدادی از تصمیماتی که برای معماری سیستم گرفته می‌‌شود ممکن است به نحوی در کارایی سیستم تاثیر بگذارد که حل آن‌‌ها بوسیله بهینه‌‌سازی در آینده دشوار باشد. این امکان وجود دارد هنگامی که این کار آسان است افرادی که در پروژه درگیر شده‌‌اند، نگران تصمیماتی باشند که پیش از این گرفته شده است.
    همیشه دشواره بوده است درباره کارایی در کتابی مثل این کتاب صحبت شود. دلایلی که این کار را سخت‌‌ کرده است، این می‌‌باشد که بسیار دشوار است هرگونه پیشنهاد و راهنمایی درباره کارایی، نباید به عنوان یک واقعیت بدون چون و چرا در نظر گرفته شود تا زمانی که در سیستم اندازه گیری شود. در خیلی موارد در طراحی‌‌ها مورد استفاده یا رد شده دیده‌‌ام بخاطر ملاحضات در کارایی مواردی به اشتباه قضاوت شده اند.

 


  یک تغییر مهم در پیکربندی سیستم ممکن است باعث نامعتبر شدن تمام موارد درباره کارایی شود. در نتیجه اگر شما به یک ماشین مجازی جدید، سخت افزاز، پایگاه-داده و تقریبا تمام موارد دیگر را آپگرید کنید. شما باید دوباره بهبود کارایی را اندازه‌‌گیری کنید تا مطمئن شوید  این تغییرات کمک کرده است. در بسیاری از موارد یک پیکربندی جدید خیلی از چیز‌‌ها را می‌‌تواند تغییر بدهد. در واقع ممکن است شما متوجه شوید که یک بهینه‌‌سازی که شما در گذشته برای بهبود کارایی انجام داده‌‌اید در واقع باعث کاهش کارایی در محیط جدید شده است.
    مشکل دیگری که درباره کارایی وجود دارد این حقیقت است که بسیاری از عبارات درباره کارایی بصورت متناقضی استفاده شده‌‌اند. موردی که بسیاری از موارد قربانی بوده است  کلمه "مقیاس پذیری" است، که به انواع حالات تفسیر شده است. عبارت‌‌هایی که من استفاده می‌‌کنم در پایین توضیح داده شده‌‌اند.
    زمان پاسخ مقدار زمانی است که سیستم نیاز دارد تا یک درخواست از بیرون را پردازش کند. این عملیات می‌‌تواند یک عمل در رابط کاربری  مانند فشار دادن یک دکمه یا درخواست API از سمت سرور باشد.
    پاسخگویی این است که سیستم با چه سرعتی تشخیص می‌‌دهد پروسه درحال انجام در چه مرحله‌‌ای می‌‌باشد. در بسیاری از سیستم‌‌ها این مورد بسیار مهم است زیرا ممکن است باعث  خستگی کاربر شود، حتی اگر زمان پاسخ مناسب باشد. اگر سیستم در کل دوره درخواست منتظر باشد در این حالت پاسخگویی و زمان پاسخ شما یکی است. اگر شما مشخص کنید که شما درخواست را دریافت کرده‌‌اید قبل از این که درخواست تکمیل شود در این حالت پاسخگویی بهتر می‌‌شود. نمایش یک نشان دهنده پیشرفت هنگام کپی شده یک فایل اگرچه باعث بهبود زمان پاسخ نمی‌‌شود ولی باعث پاسخگویی بهتر رابط کاربری می‌‌شود.
    تاخیر کمترین زمانی که نیاز است که هرگونه پاسخی گرفته شود. حتی اگر کاری که باید انجام شود وجود نداشته باشد. بطور معمول بزرگترین مشکل در سیستم‌‌های از راه دور است. اگر من از یک برنامه بخواهم کاری انجام ندهد، اما به من اطلاع بدهد که انجام هیچ چیز به  پایان رسیده است، در این حالت من باید یک پاسخ، در لحظه دریافت کنم اگر برنامه درحال اجرا برروی لپ‌‌تاپ من باشد. درحالی که اگر برنامه در حال اجرا برروی یک کامپیوتر از راه دور باشد ممکن است این پاسخ کمی طولانی‌‌تر بشود زیرا زمانی نیاز است برای درخواست و پاسخ که از طریق سیم‌‌ها رد و بدل می‌‌شود. بعنوان یک توسعه‌‌دهنده نرم‌‌افزار هیچ کاری برای کاهش تاخیر نمی‌‌توانیم انجام بدهیم. تاخیر همچنین یک دلیل خوب برای این است که چرا باید تماس‌‌های راه دور را به حداقل برسانیم.
    بازده به این معنا است که چه مقدار کار شما در یک بازه زمانی مشخص انجام می‌‌دهید. اگر شما کپی کردن یک فایل را زمان می‌‌گیرید، بازده می‌‌تواند مقدار بایت‌‌هایی باشد که در هر ثانیه منتقل می‌‌شود. برای نرم-افزارهای تجاری یک اندازه‌‌گیری معمول تعداد تراکنش‌‌ها (tps) در ثانیه می‌‌باشد. شما برای سیستم خودتان باید یک گروه از تراکنش‌‌های خاص را در نظر بگیرید.
    در این زمینه کاری کارایی، می‌‌تواند بازده یا زمان پاسخ یا هرکدام که برای شما مهم است باشد. گاهی صحبت درباره کارایی سخت است. هنگامی که یک تکنیک بازده را افزایش می‌‌دهد اما زمان پاسخ را کاهش می-دهد. بنابراین بهتر است از این عبارات دقیقتر استفاده کنیم. از دید یک کاربر ممکن است پاسخگویی از زمان پاسخ مهمتر باشد. بنابراین اگر پاسخگویی را بهتر کنیم حتی اگر به قیمت افزایش زمان پاسخ و بازده باشد، کارایی افزایش می‌‌یابد.
    بارِ کاری (Work load) یک عبارت است که سیستم چقدر تحت فشار است که معمولا بوسیله تعداد کاربرانی که درحال حاضر به سیستم متصل هستند سنجیده می‌‌شود. معمولا بار کاری برای دیگر اندازه‌‌گیری‌‌ها استفاده می-شود. به عنوان نمونه زمان پاسخ یکی از آن‌‌ها می‌‌باشد. بطور مثال ممکن است شما بگویید زمان پاسخ برای یک درخواست برابر با 5/0 ثانیه است هنگامی که بار کاری برابر با 10 کاربر می‌‌باشد و برابر با 2 ثانیه هنگامی که بار کاری برابر با 20 کاربرآنلاین می‌‌باشد.

 


    حساسیت به بار کاری یک عبارت است که نشان می‌‌دهد زمان پاسخ چگونه با تغییر بارکاری تغییر می‌‌کند. بیاید در نظر بگیریم سیستم A زمان پاسخی برابر با نیم ثانیه برای بارکاری 10 و 20 نفر دارد. در حالی که در سیستم B زمان پاسخ دو دهم ثانیه برای بارکاری 10 کاربر دارد که با افزایش بارکاری به 20 نفر به 2 ثانیه می‌‌رسد. در این حالت سیستم A حساسیت به بارکاری کمتری نسبت به سیستم B دارد. ما حتی ممکن است از عبارت تنزل استفاده کنیم تا بگوییم سیستم B تنزل بیشتری از سیستم A داشته است.
    بهره وری همان کارایی است که بوسیله منابع تقسیم شده است. یک سیستم که tps آن برابر با 30 است و با دو CPU کار می‌‌کند، بهره‌‌ورتر از سیستمی است که tps آن برابر با 40 است و با 4 CPU از همان نوع سیستم اولی کار می‌‌کند.
    ظرفیت یک سیستم  حداکثر میزان بارکاری یا بازده سیستم است که بطور موثری سیستم می‌‌تواند تحمل کند. این می‌‌تواند کاملا بی‌‌نهایت یا یک مقدار مشخص باشد که کارایی سیستم به یک دفعه به میزان غیرقابل قبولی می‌‌رسد.
    مقیاس پذیری یک مقیاس است که نشان می‌‌دهد افزایش منابع (بطور معمول سخت‌‌افزار) چگونه برکارایی تاثیر می‌‌گذارد. یک سیستم مقیاس‌‌پذیر سیستمی هست که به شما اجازه می‌‌دهد که به آن سخت‌‌افزار اضافه کنید و یک بهبود کارایی در کیفیت بگیرید، به طور مثال با دو برابر کردن سرورها بازده خود را دو برابر کنید. مقیاس‌‌پذیری عمودی یا مقیاس رو به بالا به معنی افزایش قدرت یک سرور است. و مقیاس‌‌پذیری افقی یا مقیاس رو به دو طرف به معنی افزایش تعداد سرورها می‌‌باشد.
    مشکل این است که تصمیمات طراحی بر تمام مسائل مربوط به کارایی به طور یکسان تاثیر نمی‌‌گذارد. در نظر بگیرید که دو نرم‌‌افزار بر روی یک سرور در حال اجرا هستند: ظرفیت Swordfish برابر با tps 20 در حالی که ظرفیت Camel برابر با tps 40 می‌‌باشد. کدامیک کارایی بهتری دارند؟ ما فقط می‌‌توانیم بگوییم Camel بر روی یک سرور بهره‌‌ورتر است. اگر ما یک سرور دیگر اضافه کنیم متوجه خواهیم شد که در این لحظه Swordfish tps 35  را مدیریت می‌‌کند و Camel tps50 را مدیریت می‌‌کند. ظرفیت Camel هنوز هم بیشتر است، اما به نظر می‌‌رسد مقیاس‌‌پذیری رو به دو طرف Swordfish بهتر است. اگر ما افزایش سرور را ادامه دهیم. متوجه خواهیم شد Swordfish tps15 رشد می‌‌کند با افزایش هر سرور در حالی که این افزایش برای Camel برابر با tps10 می‌‌باشد. با توجه به این اطلاعات می‌‌توانیم بگوییم Swordfish مقیاس-پذیری افقی بهتری دارد. با این که Camel بهره‌‌وری بیشتری برای زمانی که تعداد سرورها کمتر از 5 است دارد.
    هنگام ساختن سیستم‌‌های تجاری، مقیاس‌‌پذیری به شما اختیار کارایی بهتر در صورت نیاز را می‌‌دهد. همچنین انجام مقیاس‌‌پذیری آسان‌‌تر می‌‌شود. اغلب طراح‌‌ها کارهای پیچیده انجام می‌‌دهند تا ظرفیت بر روی یک پلتفرم سخت‌‌افزاری خاص بهبود ببخشند. همینطور به نظر می‌‌آید این کار از خرید سخت-افزار بیشتر هزینه کمتری خواهد داشت. Camel هزینه بیشتری نسبت به Swordfish دارد، این بها برابر با چندین سرور است. Swordfish زمانی ارزان‌‌تر خواهد شد که شما به tps40 یا بیشتر نیاز داشته باشید. بسیار معمول است که شکایت کنیم درباره اینکه با بهتر کردن سخت‌‌افزار می‌‌توانیم اجرای مناسبی از برنامه‌‌هایمان داشته باشیم. من هم به این گروه ملحق می‌‌شوم هنگامی که مجبور می‌‌شوم لپ‌‌تاپم را آپگرید کنم تا آخرین نسخه Word را اجراء کنم. اما سخت‌‌افزار جدید معمولا ارزان‌‌تر از این است که برنامه را به حالتی در بیاوریم که با سیستم‌‌های قدیمی هم کار کند. به همین ترتیب افزایش سرورها معمولا هزینه کمتری به این دارد که برنامه‌‌نویس‌‌ها را افزایش دهیم.

 


نظرات

8. ساختار الگو های طراحی

ساختار الگو ها در طراحی سیستم های نرم افزاری و مسائل پیاده...

ادامه مطلب

7. الگو های طراحی نرم افزار

هر الگویی یک مشکل را تعریف می کند که به طور مرتب...

ادامه مطلب

5. انواع نرم افزار های تجاری

نرم افزارهای تجاری همگی متفاوت هستند و این مشکلات متفاوت نیازمند برخوردهای...

ادامه مطلب

6. کارایی نرم افزار های تجاری

تاملی درباره کارایی سیستم های نرم افزاری و تصمیماتی که بخاطر کارایی سیستم در مرحله معماری گرفته می شود


مقالات بیشتر در زمینه طراحی سیستم