کتاب Understanding Software Dynamics یا درک پویایی نرم افزار سعی شده با ارائه راهکارهای متفاوت شما را با مسائل سخت و پیچیدهی حوزهی مهندسی نرمافزار و نیز مدیریت نرمافزار آشنا کند.
در کتاب Understanding Software Dynamics، کارشناس عملکرد، Richard L. Sites، با ارائه روشهای خبره و ابزارهای پیشرفته برای درک پویایی نرم افزار پیچیده و با زمان محدود، بهبود قابلیت اطمینان و عیبیابی مشکلات عملکرد چالش برانگیز، با این مشکل مقابله میکند.
در ادامه مقدمهای از کتاب Understanding Software Dynamics را از زبان نویسنده شرح خواهیم داد.
مقدمهای بر کتاب Understanding Software Dynamics:
درک عملکرد نرمافزارهای پیچیده دشوار است. زمانی که آن نرمافزار محدود به زمان باشد و به طور مرموزی از محدودیتهای خود گاه و بیگاه فراتر رود، دشوارتر است. متخصصان نرمافزار در ذهن خود تصاویری از پویایی اجرای نرمافزار خود دارند: اینکه چگونه قطعات مختلف در طول زمان با هم کار میکنند و با هم تعامل دارند و تخمین میزند که هر قطعه چقدر طول میکشد. (گاهی اوقات آنها حتی آن تصاویر را مستند میکنند.) اما زمانی که محدودیتهای زمانی برآورده نمیشود، ما ابزار کمی برای درک چرایی آن داریم – برای یافتن علت(های) اصلی تأخیر و سایر ناهنجاریهای عملکرد.
کتاب Understanding Software Dynamics یک کتاب درسی برای توسعهدهندگان نرمافزار و دانشآموزان پیشرفتهای است که روی چنین نرمافزارهایی کار میکنند.
پویایی نرمافزار نه تنها به عملکرد یا زمان اجرای یک رشته برنامه، بلکه به تعاملات بین رشتهها، بین برنامههای نامرتبط، و بین یک سیستم عامل و برنامههای کاربر اشاره دارد. تأخیر در نرمافزارهای پیچیده اغلب به دلیل این تعاملات ایجاد میشود – مسدود شدن کد و انتظار برای بیدار کردن کدهای دیگر، کد قابل اجرا در انتظار برنامهریزی برای تخصیص CPU برای اجرا به آن، اجرای کند کد به دلیل تداخل سختافزار مشترک از کدهای دیگر.
کد به هیچ وجه اجرا نمیشود زیرا یک روال وقفه از CPU خود استفاده میکند، کد به طور نامرئی بیشتر وقت خود را در سرویسهای سیستم عامل یا در رسیدگی به خطاهای صفحه صرف میکند، کد در انتظار دستگاههای ورودی/خروجی یا پیامهای شبکه از رایانههای دیگر و غیره میباشد.
نرمافزار با محدودیت زمانی وظایف مکرری را انجام میدهد که دارای ضربالاجلهای دورهای هستند یا وظایفی که نرخ ورود نامتناسب درخواستهای جدید دارند که هر کدام یک مهلت دارند. این وظایف میتوانند دارای مهلتهای سخت برای ارسال سیگنالهای کنترلی به ماشینهای متحرک (هواپیما، اتومبیل، روباتهای صنعتی)، ضربالاجلهای ملایم مانند تبدیل گفتار به متن در حین پرواز، یا فقط ضربالاجلهای آرزویی مانند جستجوی پایگاه داده مشتری یا پاسخ جستجوی وب باشند.
محدودیت زمان برای پاسخهای رابط کاربری تلفن/تبلت/رومیزی/بازی نیز اعمال میشود. اصطلاح زمان محدود گستردهتر از اصطلاح بلادرنگ است که اغلب بر محدودیتهای سخت دلالت دارد.
در هر مورد، وظایف نرمافزاری یک محرک یا درخواست و یک نتیجه یا پاسخ دارند. زمان سپری شده بین محرک و نتیجه، تأخیر یا زمان پاسخ، مهلتی دارد. وظایفی که از ضرب الاجل خود فراتر میروند، گاهی به روشهای فاجعهبار و گاهی صرفاً به روشهای ناامید کننده شکست میخورند. شما یاد خواهید گرفت که چگونه دلایل اصلی این شکستها را پیدا کنید.
وظایف فردی در چنین نرمافزاری را میتوان تراکنش، پرسوجو، پاسخهای کنترلی یا واکنشهای بازی نامید. در اینجا ما از اصطلاح تراکنش استفاده میکنیم تا همه اینها را در بر گیرد. اغلب یک کار انتها به پایان از چندین کار فرعی تشکیل شده است که برخی از آنها به صورت موازی اجرا میشوند و برخی از آنها به تکمیل وظایف فرعی دیگر بستگی دارد.
وظایف فرعی ممکن است محدود به CPU، محدود به حافظه، محدود به دیسک یا محدود به شبکه باشند. ممکن است به دلیل تداخل در منابع سختافزاری مشترک یا به دلیل استراتژیهای صرفهجویی در مصرف انرژی در تراشههای CPU مدرن، آنها آهستهتر از حد انتظار اجرا شوند. آنها ممکن است منتظر باشند (یعنی اجرا نشوند) برای قفلهای نرمافزاری یا پاسخهای سایر وظایف یا رایانههای دیگر یا دستگاههای خارجی. ممکن است تأخیر یا تداخل غیرمنتظرهای از سوی سیستم عامل اصلی یا درایورهای دستگاه حالت هسته آن به جای کد حالت کاربر برنامهنویس وجود داشته باشد.
در بسیاری از موقعیتها، نرمافزار درگیر شامل دهها یا چند لایه یا زیرسیستم است که همگی ممکن است به تأخیرهای غیرمنتظره کمک کنند و همگی ممکن است روی رایانههای شبکهای جداگانه اجرا شوند. به عنوان مثال، یک جستجوی وب گوگل ممکن است پرس و جو را در 2000 رایانه پخش کند، که هر کدام بخش کوچکی از جستجو را انجام میدهند و سپس نتایج به عقب منتقل میشوند و اولویتبندی میشوند.
دریافت پیام ایمیل در فضای ابری ممکن است سیستمهای فرعی را برای پایگاههای داده، ذخیرهسازی دیسک شبکه، نمایهسازی، قفل کردن، رمزگذاری، تکرار، و انتقال بین قارهای فعال کند. یک رایانه رانندگی اتومبیل ممکن است 50 برنامه مختلف را اجرا کند، که برخی از آنها بر روی هر فریم ویدیویی که از دوربینهای نیمدوجین میآید، بهعلاوه بازگشت رادار، تغییر مختصات GPS، تغییر نیروهای شتاب سهبعدی در خودرو، و بازخورد در مورد باران، تعامل دارند.
دید، لغزش لاستیک، و غیره. یک سیستم پایگاه داده کوچک ممکن است دارای بهینهسازی پرس و جو و زیرسیستمهای دسترسی به دیسک با استفاده از دهها دیسک پراکنده در چندین کامپیوتر شبکه ای باشد. یک بازی میتواند دارای زیرسیستمهایی برای محاسبات محلی، پردازش گرافیکی و تعاملات شبکهای با سایر بازیکنان باشد.
شما در کتاب Understanding Software Dynamics یاد خواهید گرفت که چگونه برای چنین نرمافزارهایی از نظر قابلیت مشاهده، ثبتنام و مُهرهای زمانی طراحی کنید، چگونه رفتار CPU/حافظه/دیسک/شبکه را اندازهگیری کنید، چگونه ابزارهای مشاهدهای کمسرد طراحی کنید، و چگونه در مورد دادههای عملکرد حاصل استدلال کنید.
هنگامی که تصویر دقیقی از وظایف و وظایف فرعی زمان سپری شده واقعی برای تراکنشهای عادی و همچنین برای تراکنشهای کند داشته باشید، میتوانید ببینید که این واقعیت چگونه با تصویری که در ذهن شما وجود دارد متفاوت است.
در آن مرحله، بهبود قابل ملاحظه تراکنشهای کند ممکن است تنها 20 دقیقه از تغییرات نرمافزاری را ببرد. اما بدون یک تصویر خوب از واقعیت، برنامهنویسان به حدس زدن و “آزمایش چیزها” برای کاهش تاخیرهای طولانی و بهبود عملکرد محدود میشوند. کتاب Understanding Software Dynamics در مورد حدس زدن نیست، بلکه دانستن است.
تمامی مثالها، تمرینهای برنامهنویسی و نرمافزارهای ارائهشده در کتاب Understanding Software Dynamics به زبان C یا C++ بر اساس سیستمعامل لینوکس که بر روی پردازندههای AMD ،ARM یا اینتل ۶۴ بیتی اجرا میشود، نوشته شدهاند.
فرض بر این است که خواننده با توسعه نرمافزار در این محیط آشنا است. همچنین فرض میکنیم که خواننده نرمافزاری دارد که زمان محدودی دارد و مشکلات عملکردی دارد که خواننده میخواهد آنها را برطرف کند.
نرمافزار باید از قبل کاربردی باشد و اشکالزدایی شده باشد، با عملکرد متوسط قابل قبول – مشکل فقط واریانس عملکرد غیرقابل توضیح است. فرض بر این است که خواننده تصویری از نحوه اجرای نرمافزار دارد و در صورت درخواست میتواند نحوه تعامل قطعات در یک تراکنش معمولی را ترسیم کند. در نهایت، فرض بر این است که خواننده اطلاعات کمی در مورد پردازندهها، حافظه مجازی، ورودی/خروجی دیسک و شبکه، قفلهای نرمافزار، اجرای چند هستهای و پردازش موازی دارد. با هم، آن را از آنجا خواهیم گرفت.
ما سه موضوع اصلی را بررسی میکنیم: اندازهگیری، مشاهده و دلیل.
اندازه گرفتن. محل شروع هر مطالعه عملکرد اندازهگیری آنچه اتفاق میافتد است. یک اندازهگیری عددی – تراکنشها در ثانیه، زمان پاسخدهی صدک 99 یا تعداد فریمهای ویدئویی کاهش یافته – فقط به شما میگوید چه اتفاقی میافتد، اما دلیل آن را نه.
رعایت کنید. برای درک اینکه چرا برخی از اندازهگیریها به طور غیرمنتظرهای کند یا بد هستند، اما اندازهگیری دوباره همان کار سریع است، باید با جزئیات دقیق مشاهده کرد که تمام زمان در کجا میگذرد یا چه پردازشی برای نمونههای عادی و آهسته انجام میشود. برای مورد سخت رفتار غیرمنتظره بد که فقط تحت بار زنده سنگین رخ میدهد، لازم است که در یک بازه زمانی قابل توجه به اندازه کافی مشاهده شود تا احتمال بالایی برای مشاهده چندین نمونه آهسته وجود داشته باشد و این کار در محل با حداقل اعوجاج در حین اجرای زنده کامل بارها انجام شود.
دلیل (و اصلاح). هنگامی که مشاهدات دقیق در دسترس هستند، باید در مورد آنچه میبینید استدلال کنید – نمونههای کند چگونه با نمونههای معمولی متفاوت هستند، چگونه تعاملات نرمافزاری و سختافزاری نمونههای کند ایجاد میکنند، و چگونه میتوانید وضعیت را بهبود بخشید؟ در بخش آخر کتاب Understanding Software Dynamics، نمونههای موردی این گونه استدلالها و برخی از اصلاحات را مرور میکنیم.
پس از این مضامین، مطالب کتاب Understanding Software Dynamics به چهار بخش، از جمله بخشی در مورد ساخت ابزار مشاهده کم سربار KUtrace سازماندهی شده است:
بخش اول (فصل 1-7) کتاب Understanding Software Dynamics، اندازهگیری – نحوه اندازهگیری دقیق چهار منبع اصلی رایانه: CPU، حافظه، دیسک/SSD و شبکه.
بخش دوم (فصل 8-13) کتاب Understanding Software Dynamics، مشاهده-ابزارهای مشاهده معمولی: ثبت گزارش، داشبورد، شمارش/پروفایل/نمونهبرداری و ردیابی.
بخش سوم (فصل 14-19) کتاب Understanding Software Dynamics، ردیابی هسته-کاربر – طراحی و ساخت یک ابزار ردیابی لینوکس کم سربار که کارهایی را که هر هسته CPU در هر نانوثانیه انجام میدهد را ثبت میکند، همراه با برنامههای پس پردازش برای ایجاد صفحات HTML پویا که نمایشگر جدول زمانی و تعاملات حاصل.
بخش چهارم (فصل 20-30) کتاب Understanding Software Dynamics، استدلال-مطالعات موردی استدلال در مورد تداخل زمینهای تاخیرهای غیرمعمول مشاهده شده در موارد زیر است:
اجرای بیش از حد، اجرای آهسته دستورالعمل، انتظار برای CPU، حافظه، دیسک، شبکه، قفلهای نرمافزار، صفها و تایمرها.
با استفاده از این ایدهها، میتوانید این تصویر تاخیر غیرقابل توضیح را تغییر دهید:
در تصویر دقیق زیر که نشان میدهد کدام وظایف فرعی چه زمانی اتفاق افتاده است، چه کارهایی به صورت موازی اتفاق میافتد، که بستگی به تکمیل مرحله دیگر دارد، و بنابراین دقیقاً چرا سه ساعت طول کشید:
همین ایدهها میتوانند یک نمونه تأخیر نرمافزاری را به این تصویر از دیمون ssh ورود از راه دور در CPU 2 تبدیل کنند که gedit را در CPU 1 بیدار میکند:
(در قسمت سوم شما یاد خواهید گرفت که چگونه آخرین نوع تصویر را برای نرمافزار دلخواه خود ایجاد کنید.)
کتاب Understanding Software Dynamics به ویژه برای خوانندگانی در نظر گرفته شده است که تکالیف برنامهنویسی گنجانده شده را انجام میدهند و بخشهایی از ابزارهای مشاهده نرمافزار توضیح داده شده را اجرا میکنند.
در سراسر کتاب Understanding Software Dynamics نظراتی در مورد تراشههای پردازشگر پیچیده مدرن و مکانیسمهای افزایش عملکرد آنها وجود دارد. شکست تصادفی این مکانیسمها میتواند تاخیرهای شگفتانگیزی ایجاد کند. خواننده دقیق، درک عمیقتری از معماری کامپیوتر و ریزمعماری، همراه با هر چیز دیگری به دست خواهد آورد.
کتاب Understanding Software Dynamics درسی برای متخصصان نرمافزار و دانش آموزان پیشرفته است. اما مطالب مورد علاقه معماران سختافزار کامپیوتر، توسعهدهندگان سیستم عامل، متخصصان فناوری اطلاعات معماری سیستم، طراحان سیستم بلادرنگ و توسعهدهندگان بازی را نیز پوشش میدهد. تمرکز آن بر درک تأخیر مواجهه با کاربر، مهارتهایی را ایجاد میکند که حرفه هر برنامهنویسی را ارتقا میبخشد.
علاوه بر کتاب Understanding Software Dynamics، شما میتوانید از کتاب Software Engineering for Absolute Beginners جهت درک مباحث مهندسی نرمافزار استفاده نمائید.
سرفصلهای کتاب Understanding Software Dynamics:
- Foreword
- Preface
- Acknowledgments
- About the Author
- I Measurement
- 1 My Program Is Too Slow
- 2 Measuring CPUs
- 3 Measuring Memory
- 4 CPU and Memory Interaction
- 5 Measuring Disk/SSD
- 6 Measuring Networks
- 7 Disk and Network Database Interaction
- II Observation
- 8 Logging
- 9 Aggregate Measures
- 10 Dashboards
- 11 Other Existing Tools
- 12 Traces
- 13 Observation Tool Design Principles
- III Kernel-User Trace
- 14 KUtrace: Goals, Design, Implementation
- 15 KUtrace: Linux Kernel Patches
- 16 KUtrace: Linux Loadable Module
- 17 KUtrace: User-Mode Runtime Control
- 18 KUtrace: Postprocessing
- 19 KUtrace: Display of Software Dynamics
- IV Reasoning
- 20 What to Look For
- 21 Executing Too Much
- 22 Executing Slowly
- 23 Waiting for CPU
- 24 Waiting for Memory
- 25 Waiting for Disk
- 26 Waiting for Network
- 27 Waiting for Locks
- 28 Waiting for Time
- 29 Waiting for Queues
- 30 Recap
- A Sample Servers
- B Trace Entries
- Glossary
- References
- Index
فایل کتاب Understanding Software Dynamics را میتوانید پس از پرداخت، دریافت کنید.
دیدگاهها
هیچ دیدگاهی برای این محصول نوشته نشده است.