برنامه های کاربردی وب اکنون در همه جا مورد استفاده قرار می گیرند و در میان تمام پروتکل های انتقال، HTTP سهم بزرگی را به خود اختصاص می دهد. هنگام مطالعه تفاوت های ظریف توسعه برنامه های کاربردی وب، اکثر مردم به سیستم عاملی که این برنامه ها واقعاً در آن اجرا می شوند توجه بسیار کمی دارند. جداسازی توسعه (Dev) و عملیات (Ops) فقط وضعیت را بدتر کرد. اما با ظهور فرهنگ DevOps، توسعه‌دهندگان مسئول اجرای برنامه‌های خود در فضای ابری می‌شوند، بنابراین آشنایی کامل با باطن سیستم عامل برای آنها بسیار مفید است. این به ویژه در صورتی مفید است که می خواهید یک سیستم را برای هزاران یا ده ها هزار اتصال همزمان مستقر کنید.

محدودیت ها در وب سرویس ها بسیار شبیه به سایر برنامه ها است. خواه متعادل کننده بار یا سرورهای پایگاه داده، همه این برنامه ها مشکلات مشابهی در یک محیط با کارایی بالا دارند. درک این محدودیت های اساسی و نحوه غلبه بر آنها به طور کلی به شما کمک می کند تا عملکرد و مقیاس پذیری برنامه های کاربردی وب خود را ارزیابی کنید.

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

لینوکس است اتاق سرور سیستم عامل و اغلب برنامه های شما بر روی این سیستم عامل اجرا می شوند. اگرچه من می گویم "لینوکس"، اما در بیشتر مواقع می توانید با خیال راحت فرض کنید که منظور من به طور کلی تمام سیستم عامل های مشابه یونیکس است. با این حال، من کد همراه را در سیستم های دیگر تست نکرده ام. بنابراین، اگر به FreeBSD یا OpenBSD علاقه دارید، نتایج شما ممکن است متفاوت باشد. وقتی چیزی خاص لینوکس را امتحان می کنم، به آن اشاره می کنم.

در حالی که می توانید از این دانش برای ساختن یک برنامه از ابتدا استفاده کنید و کاملاً بهینه می شود، بهتر است این کار را نکنید. اگر یک وب سرور جدید به زبان C یا C++ برای برنامه تجاری سازمان خود بنویسید، ممکن است این آخرین روز کاری شما باشد. با این حال، دانستن ساختار این برنامه ها به انتخاب برنامه های موجود کمک می کند. شما می‌توانید سیستم‌های مبتنی بر فرآیند را با سیستم‌های مبتنی بر رشته و همچنین سیستم‌های مبتنی بر رویداد مقایسه کنید. متوجه خواهید شد و درک خواهید کرد که چرا Nginx بهتر از Apache httpd عمل می کند، چرا یک برنامه پایتون مبتنی بر تورنادو می تواند در مقایسه با برنامه پایتون مبتنی بر جنگو به کاربران بیشتری خدمات رسانی کند.

ZeroHTTPd: ابزار یادگیری

ZeroHTTPd یک وب سرور است که من از ابتدا در C به عنوان یک ابزار آموزشی نوشتم. هیچ وابستگی خارجی از جمله دسترسی به Redis ندارد. ما رویه های Redis خود را اجرا می کنیم. برای اطلاعات بیشتر قسمت زیر را مطالعه کنید.

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

نظرات زیادی در کد وجود دارد که به درک شما کمک می کند. ZeroHTTPd به عنوان یک وب سرور ساده در چند خط کد، یک چارچوب حداقلی برای توسعه وب است. عملکرد محدودی دارد، اما می‌تواند فایل‌های استاتیک و صفحات «دینامیک» بسیار ساده را ارائه دهد. باید بگویم که ZeroHTTPd برای یادگیری نحوه ایجاد برنامه های لینوکس با کارایی بالا خوب است. به طور کلی، اکثر سرویس های وب منتظر درخواست ها هستند، آنها را بررسی می کنند و آنها را پردازش می کنند. این دقیقا همان کاری است که ZeroHTTPd انجام خواهد داد. این ابزاری برای یادگیری است نه تولید. در رسیدگی به خطاها عالی نیست و بعید است که بهترین شیوه های امنیتی را به رخ بکشد (اوه بله، من استفاده کردم strcpy) یا ترفندهای زیرکانه زبان C. اما امیدوارم کار خود را به خوبی انجام دهد.

صفحه اصلی ZeroHTTPd. این می تواند انواع فایل های مختلف از جمله تصاویر را خروجی دهد

اپلیکیشن کتاب مهمان

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

برنامه وب "کتاب مهمان" ZeroHTTPd

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

شکل زیر نشان می دهد که برنامه در هنگام درخواست مشتری (مرورگر) چه کاری انجام می دهد /guestbookURL.

اپلیکیشن کتاب مهمان چگونه کار می کند

هنگامی که یک صفحه کتاب مهمان باید صادر شود، یک تماس با سیستم فایل برای خواندن الگو در حافظه و سه تماس شبکه با Redis وجود دارد. فایل قالب حاوی بیشتر محتوای HTML صفحه در تصویر بالا است. همچنین متغیرهای خاصی برای بخش پویا محتوا وجود دارد: پست ها و شمارنده بازدیدکنندگان. ما آنها را از Redis دریافت می کنیم، آنها را در صفحه قرار می دهیم و محتوای کاملاً شکل گرفته را در اختیار مشتری قرار می دهیم. از سومین فراخوانی به Redis می توان اجتناب کرد زیرا Redis هنگام افزایش مقدار کلید جدید را برمی گرداند. با این حال، برای سرور ما، که دارای معماری مبتنی بر رویداد ناهمزمان است، بسیاری از تماس‌های شبکه آزمون خوبی برای اهداف یادگیری هستند. بنابراین مقدار بازگشتی Redis را از تعداد بازدیدکنندگان حذف می کنیم و با یک فراخوان جداگانه آن را پرس و جو می کنیم.

معماری سرور ZeroHTTPd

ما در حال ساخت هفت نسخه از ZeroHTTPd با عملکرد یکسان اما معماری های متفاوت هستیم:

تکراری
سرور فورک (یک پردازش فرزند در هر درخواست)
سرور پیش فورک (پیش فورک فرآیندها)
سرور با رشته های اجرایی (یک رشته در هر درخواست)
سرور با ایجاد پیش موضوع
مبتنی بر معماری poll()
مبتنی بر معماری epoll

ما عملکرد هر معماری را با بارگذاری سرور با درخواست های HTTP اندازه گیری می کنیم. اما هنگام مقایسه معماری های بسیار موازی، تعداد پرس و جوها افزایش می یابد. سه بار تست می کنیم و میانگین را محاسبه می کنیم.

روش شناسی تست

نصب تست بار ZeroHTTPd

مهم است که هنگام اجرای آزمایش ها، همه اجزا بر روی یک دستگاه اجرا نشوند. در این مورد، سیستم‌عامل سربار زمان‌بندی اضافی را متحمل می‌شود زیرا اجزا برای CPU رقابت می‌کنند. اندازه گیری سربار سیستم عامل هر یک از معماری های سرور انتخاب شده یکی از مهمترین اهداف این تمرین است. افزودن متغیرهای بیشتر برای فرآیند مضر خواهد بود. بنابراین، تنظیمات در تصویر بالا بهترین عملکرد را دارد.

هر کدام از این سرورها چه کاری انجام می دهند؟

load.unixism.net: این جایی است که ما اجرا می کنیم ab، ابزار محک آپاچی. بار مورد نیاز برای آزمایش معماری سرور ما را تولید می کند.
nginx.unixism.net: گاهی اوقات می خواهیم بیش از یک نمونه از یک برنامه سرور را اجرا کنیم. برای انجام این کار، سرور Nginx با تنظیمات مناسب به عنوان متعادل کننده بار کار می کند ab به فرآیندهای سرور ما
zerohttpd.unixism.net: در اینجا ما برنامه های سرور خود را بر روی هفت معماری مختلف اجرا می کنیم.
redis.unixism.net: این سرور شبح Redis را اجرا می‌کند، جایی که ورودی‌های کتاب مهمان و شمارنده‌های بازدیدکننده ذخیره می‌شوند.

همه سرورها بر روی یک هسته پردازنده اجرا می شوند. ایده این است که حداکثر عملکرد هر معماری را ارزیابی کنیم. از آنجایی که همه برنامه های سرور بر روی یک سخت افزار آزمایش می شوند، این یک پایه برای مقایسه است. راه اندازی آزمایشی من شامل سرورهای مجازی است که از Digital Ocean اجاره شده اند.

چه چیزی را اندازه می گیریم؟

شما می توانید شاخص های مختلف را اندازه گیری کنید. ما عملکرد هر معماری را در یک پیکربندی معین با بارگذاری سرورها با درخواست هایی در سطوح مختلف موازی ارزیابی می کنیم: بار از 20 به 15 کاربر همزمان افزایش می یابد.

نتایج آزمون

نمودار زیر عملکرد سرورها را در معماری های مختلف در سطوح مختلف موازی نشان می دهد. محور y تعداد درخواست ها در ثانیه است، محور x اتصالات موازی است.

در زیر جدولی با نتایج ارائه شده است.

درخواست ها در ثانیه

موازی کاری
تکرار شونده
چنگال
پیش چنگال
جریان
قبل از پخش
نظرسنجی
epoll

20
7
112
2100
1800
2250
1900
2050

50
7
190
2200
1700
2200
2000
2000

100
7
245
2200
1700
2200
2150
2100

200
7
330
2300
1750
2300
2200
2100

300
-
380
2200
1800
2400
2250
2150

400
-
410
2200
1750
2600
2000
2000

500
-
440
2300
1850
2700
1900
2212

600
-
460
2400
1800
2500
1700
2519

700
-
460
2400
1600
2490
1550
2607

800
-
460
2400
1600
2540
1400
2553

900
-
460
2300
1600
2472
1200
2567

1000
-
475
2300
1700
2485
1150
2439

1500
-
490
2400
1550
2620
900
2479

2000
-
350
2400
1400
2396
550
2200

2500
-
280
2100
1300
2453
490
2262

3000
-
280
1900
1250
2502
گسترش بزرگ
2138

5000
-
گسترش بزرگ
1600
1100
2519
-
2235

8000
-
-
1200
گسترش بزرگ
2451
-
2100

10،000
-
-
گسترش بزرگ
-
2200
-
2200

11،000
-
-
-
-
2200
-
2122

12،000
-
-
-
-
970
-
1958

13،000
-
-
-
-
730
-
1897

14،000
-
-
-
-
590
-
1466

15،000
-
-
-
-
532
-
1281

از نمودار و جدول می توان دریافت که بالای 8000 درخواست همزمان فقط دو بازیکن باقی مانده است: pre-fork و epoll. با افزایش بار، یک سرور مبتنی بر نظرسنجی بدتر از یک استریم کار می کند. معماری تاپیک قبل از ایجاد رقیبی شایسته برای epoll است، که گواهی بر این است که هسته لینوکس تا چه اندازه تعداد زیادی از رشته ها را زمان بندی می کند.

کد منبع ZeroHTTPd

کد منبع ZeroHTTPd اینجا. برای هر معماری یک دایرکتوری جداگانه وجود دارد.

ZeroHTTPd │ ├── 01_iterative │ ├── main.c ├── 02_forking │ ├── main.c ├── 03_preforking ├──. 04_ threading │ ├── main.c ├── 05_prethreading │ ├── main.c ├── 06_poll │ ├── main.c ├── 07_epoll │ └─├ └── └── └── اصلی. ├── ایندکس .html │ └── تاکس قالب‌های png └── دفترچه مهمان └── index.html

علاوه بر هفت دایرکتوری برای همه معماری ها، دو دایرکتوری دیگر در دایرکتوری سطح بالا وجود دارد: عمومی و قالب ها. اولی شامل فایل index.html و تصویر اسکرین شات اول است. می‌توانید فایل‌ها و پوشه‌های دیگری را در آنجا قرار دهید و ZeroHTTPd باید آن فایل‌های استاتیک را بدون هیچ مشکلی ارائه کند. اگر مسیر در مرورگر با مسیر موجود در پوشه عمومی مطابقت داشته باشد، ZeroHTTPd به دنبال فایل index.html در این فهرست می‌گردد. محتوای کتاب مهمان به صورت پویا تولید می شود. این فقط یک صفحه اصلی دارد و محتوای آن بر اساس فایل "templates/guestbook/index.html" است. ZeroHTTPd به راحتی صفحات پویا را برای پسوند اضافه می کند. ایده این است که کاربران می توانند الگوهایی را به این دایرکتوری اضافه کنند و در صورت نیاز ZeroHTTPd را گسترش دهند.

برای ساخت هر هفت سرور، اجرا کنید make all از دایرکتوری سطح بالا - و همه بیلدها در این فهرست ظاهر می شوند. فایل های اجرایی به دنبال دایرکتوری های عمومی و قالب ها در دایرکتوری که از آن راه اندازی شده اند می گردند.

API لینوکس

برای درک اطلاعات این مجموعه مقالات، نیازی به آشنایی با API لینوکس ندارید. با این حال، توصیه می کنم در مورد این موضوع بیشتر بخوانید؛ منابع مرجع زیادی در اینترنت وجود دارد. اگرچه ما به چندین دسته از APIهای لینوکس خواهیم پرداخت، اما تمرکز ما در درجه اول بر روی فرآیندها، موضوعات، رویدادها و پشته شبکه خواهد بود. علاوه بر کتاب‌ها و مقاله‌های مربوط به API لینوکس، خواندن mana برای تماس‌های سیستمی و عملکردهای کتابخانه مورد استفاده را نیز توصیه می‌کنم.

عملکرد و مقیاس پذیری

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

وظایف CPU و I/O

در نهایت، در محاسبات همیشه دو نوع کار ممکن وجود دارد: برای I/O و CPU. دریافت درخواست از طریق اینترنت (ورودی/خروجی شبکه)، ارائه فایل‌ها (ورودی/خروجی شبکه و دیسک)، ارتباط با پایگاه داده (ورودی/خروجی شبکه و دیسک) همگی فعالیت‌های ورودی/خروجی هستند. برخی از پرس و جوهای پایگاه داده می توانند کمی CPU فشرده باشند (مرتب سازی، میانگین یک میلیون نتیجه، و غیره). اکثر برنامه های کاربردی وب با حداکثر ورودی/خروجی ممکن محدود می شوند و پردازنده به ندرت با ظرفیت کامل استفاده می شود. وقتی می بینید که برخی از وظایف I/O از CPU زیادی استفاده می کنند، به احتمال زیاد نشانه ای از معماری ضعیف برنامه است. این می تواند به این معنی باشد که منابع CPU برای مدیریت فرآیند و سوئیچینگ زمینه هدر می رود - و این کاملاً مفید نیست. اگر کاری مانند پردازش تصویر، تبدیل فایل صوتی یا یادگیری ماشینی انجام می‌دهید، برنامه به منابع قدرتمند CPU نیاز دارد. اما برای اکثر برنامه ها اینطور نیست.

درباره معماری سرور بیشتر بدانید

منبع: www.habr.com

عملکرد برنامه شبکه لینوکس معرفی