کارگران Multiplex (ویژگی تجربی)

در این صفحه کارگران مالتی پلکس، نحوه نوشتن قوانین سازگار با مالتی پلکس و راه‌حل‌هایی برای محدودیت‌های خاص توضیح داده می‌شود.

کارگران Multiplex به Bazel اجازه می‌دهند تا چندین درخواست را با یک فرآیند کارگر انجام دهد. برای کارگران چند رشته ای، Bazel می تواند از منابع کمتری برای دستیابی به عملکرد مشابه یا بهتر استفاده کند. به عنوان مثال، به‌جای داشتن یک فرآیند کارگر برای هر کارگر، Bazel می‌تواند چهار کارگر مالتی پلکسی داشته باشد که با همان فرآیند کارگر صحبت می‌کنند، که سپس می‌تواند درخواست‌ها را به صورت موازی رسیدگی کند. برای زبان هایی مانند جاوا و اسکالا، این باعث صرفه جویی در زمان گرم کردن JVM و زمان کامپایل JIT می شود و به طور کلی امکان استفاده از یک حافظه پنهان مشترک بین همه کارگران از یک نوع را فراهم می کند.

بررسی اجمالی

بین سرور بازل و فرآیند کارگر دو لایه وجود دارد. برای حافظه های خاصی که می توانند فرآیندها را به صورت موازی اجرا کنند، WorkerProxy از Worker Pool یک WorkerProxy دریافت می کند. WorkerProxy درخواست ها را به همراه یک request_id به صورت متوالی به فرآیند worker ارسال می کند، فرآیند worker درخواست را پردازش می کند و پاسخ ها را به WorkerMultiplexer ارسال می کند. هنگامی که WorkerMultiplexer را دریافت می کند، request_id را تجزیه می کند و سپس پاسخ ها را به WorkerProxy صحیح باز می گرداند. درست مانند کارگران غیر مولتی پلکس، تمام ارتباطات از طریق استاندارد ورودی/خروجی انجام می شود، اما ابزار نمی تواند فقط از stderr برای خروجی قابل مشاهده توسط کاربر استفاده کند ( به زیر مراجعه کنید ).

هر کارگر یک کلید دارد. Bazel از کد هش کلید (متشکل از متغیرهای محیطی، ریشه اجرا و یادداشت) برای تعیین اینکه از کدام WorkerMultiplexer استفاده شود استفاده می کند. WorkerProxy با همان WorkerMultiplexer در صورت داشتن کد هش یکسان ارتباط برقرار می کند. بنابراین، با فرض یکسان بودن متغیرهای محیطی و ریشه اجرا در یک فراخوانی Bazel، هر یادگاری منحصربه‌فرد فقط می‌تواند یک WorkerMultiplexer و یک Worker Process داشته باشد. تعداد کل کارگران، از جمله کارگران عادی و WorkerProxy ، هنوز توسط --worker_max_instances محدود است.

نوشتن قوانین سازگار با چندگانه

فرآیند کارگر قانون باید چند رشته ای باشد تا از مزایای کارگران مالتی پلکس استفاده شود. Protobuf به یک مجموعه قوانین اجازه می دهد تا یک درخواست واحد را تجزیه کند، حتی اگر چندین درخواست در جریان وجود داشته باشد. هر زمان که پردازش کارگر درخواستی را از جریان تجزیه و تحلیل می کند، باید درخواست را در یک رشته جدید مدیریت کند. از آنجایی که رشته‌های مختلف می‌توانند همزمان تکمیل و در جریان بنویسند، فرآیند کارگر باید مطمئن شود که پاسخ‌ها به صورت اتمی نوشته شده‌اند (پیام‌ها با هم همپوشانی ندارند). پاسخ ها باید حاوی request_id درخواستی باشند که در حال رسیدگی هستند.

مدیریت خروجی مالتی پلکس

کارگران مالتی پلکس باید نسبت به کارگران سینگل پلکس مراقب خروجی خود باشند. هر چیزی که به stderr ارسال شود در یک فایل گزارش واحد به اشتراک گذاشته شده در بین همه WorkerProxy از همان نوع، که به طور تصادفی بین درخواست‌های همزمان قرار می‌گیرد، می‌رود. در حالی که تغییر مسیر stdout به stderr ایده خوبی است، آن خروجی را در قسمت output WorkResponse جمع آوری نکنید، زیرا می تواند قطعات خروجی مخدوش شده را به کاربر نشان دهد. اگر ابزار شما فقط خروجی کاربر گرا را به stdout یا stderr ارسال می کند، قبل از اینکه بتوانید کارگران مالتی پلکس را فعال کنید باید این رفتار را تغییر دهید.

فعال کردن کارگران مالتی پلکس

کارگران Multiplex به طور پیش فرض فعال نیستند. یک مجموعه قوانین می تواند با استفاده از تگ supports-multiplex-workers در execution_requirements یک اقدام، کارگران مالتی پلکس را روشن کند (دقیقاً مانند تگ supports-workers عادی را فعال می کند). همانطور که در مورد استفاده از کارگران عادی، یک استراتژی کارگر باید مشخص شود، یا در سطح مجموعه قوانین (به عنوان مثال، --strategy=[some_mnemonic]=worker ) یا به طور کلی در سطح استراتژی (به عنوان مثال، --dynamic_local_strategy=worker,standalone .) هیچ پرچم اضافی لازم نیست، و supports-multiplex-workers بر supports-workers اولویت دارد، اگر هر دو تنظیم شده باشند. می‌توانید با عبور از --noexperimental_worker_multiplex ، کارگران مالتی پلکس را در سراسر جهان خاموش کنید.

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

سندباکس مولتی پلکس

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

برای پشتیبانی از sandboxing چندگانه، کارگر باید از فیلد sandbox_dir از WorkRequest استفاده کند و از آن به عنوان پیشوند برای خواندن و نوشتن همه فایل ها استفاده کند. در حالی که arguments و فیلدهای inputs نسبت به یک درخواست بدون سندباکس بدون تغییر باقی می‌مانند، ورودی‌های واقعی نسبت به sandbox_dir هستند. کارگر باید مسیرهای فایل موجود در arguments ها و inputs را برای خواندن از این مسیر اصلاح شده ترجمه کند، و همچنین باید تمام خروجی ها را نسبت به sandbox_dir . این شامل مسیرهایی مانند '.'، و همچنین مسیرهای یافت شده در فایل های مشخص شده در آرگومان ها (مانند آرگومان های "argfile" ) می شود.

هنگامی که یک کارگر از sandboxing چندگانه پشتیبانی می کند، مجموعه قوانین می تواند این پشتیبانی را با افزودن supports-multiplex-sandboxing به execution_requirements یک عمل اعلام کند. Bazel سپس اگر پرچم --experimental_worker_multiplex_sandboxing پاس داده شود، یا اگر کارگر با اجرای پویا استفاده شود، از sandboxing چندگانه استفاده خواهد کرد.

فایل‌های کارگر یک مولتی پلکس sandboxed هنوز هم نسبت به فهرست کاری فرآیند کارگر هستند. بنابراین، اگر فایلی هم برای اجرای worker و هم به‌عنوان ورودی استفاده می‌شود، باید هم به‌عنوان ورودی در آرگومان flagfile و هم در tools ، executable یا runfiles شود.