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

 

  یک تغییر مهم در پیکربندی سیستم ممکن است باعث نامعتبر شدن تمام موارد درباره کارایی شود. در نتیجه اگر شما به یک ماشین مجازی جدید، سخت افزاز، پایگاه-داده و تقریبا تمام موارد دیگر را آپگرید کنید. شما باید دوباره بهبود کارایی را اندازه¬گیری کنید تا مطمئن شوید  این تغییرات کمک کرده است. در بسیاری از موارد یک پیکربندی جدید خیلی از چیز¬ها را می¬تواند تغییر بدهد. در واقع ممکن است شما متوجه شوید که یک بهینه¬سازی که شما در گذشته برای بهبود کارایی انجام داده¬اید در واقع باعث کاهش کارایی در محیط جدید شده است.
    مشکل دیگری که درباره کارایی وجود دارد این حقیقت است که بسیاری از عبارات درباره کارایی بصورت متناقضی استفاده شده¬اند. موردی که بسیاری از موارد قربانی بوده است  کلمه "مقیاس پذیری" است، که به انواع حالات تفسیر شده است. عبارت¬هایی که من استفاده می¬کنم در پایین توضیح داده شده¬اند.
    زمان پاسخ مقدار زمانی است که سیستم نیاز دارد تا یک درخواست از بیرون را پردازش کند. این عملیات می¬تواند یک عمل در رابط کاربری  مانند فشار دادن یک دکمه یا درخواست 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 را اجراء کنم. اما سخت¬افزار جدید معمولا ارزان¬تر از این است که برنامه را به حالتی در بیاوریم که با سیستم¬های قدیمی هم کار کند. به همین ترتیب افزایش سرورها معمولا هزینه کمتری به این دارد که برنامه¬نویس¬ها را افزایش دهیم.