گزینه‌های پایه (Basic options)

گزینه‌های عملیاتی (Operations options)

گزینه‌های امنیتی (Security options)

گزینه‌های پیشرفته، توسعه و اشکال‌زدایی (Advanced, development and debugging options)

الگوریتم درهم‌سازی (Hash Algorithm)

الگوریتم‌های درهم‌سازی زیر در دسترس هستند:

set beresp.storage = storage.myStorage;

-s default,100m

-s Transient=default

-j solaris,worker=basic

userdel varnish || true
userdel vcache || true
userdel varnishlog || true # to remove reference to varnish group
groupdel varnish || true

groupadd vinyl
useradd -g vinyl -d /nonexistent -s /bin/false \
  -c "Vinyl Cache Daemon User" vinyl
useradd -g vinyl -d /nonexistent -s /bin/false \
  -c "Vinyl Cache Worker User" vcache
useradd -g vinyl -d /nonexistent -s /bin/false \
  -c "Vinyl Log User" vinyllog

فایل دستورهای CLI

گزینهٔ -I اجرای دستورهای مدیریتی دلخواه را هنگام راه‌اندازی vinyld، پیش از آغاز فرایند کارگر (worker process)، ممکن می‌سازد. به‌ویژه، این روش برای بارگذاری پیکربندی‌ها، اعمال برچسب‌ها به آن‌ها، و فعال‌سازی نمونهٔ VCL در زمان راه‌اندازی که از آن برچسب‌ها استفاده می‌کند به کار می‌رود:

vcl.load panic /etc/vinyl-cache/panic.vcl
vcl.load siteA0 /etc/vinyl-cache/siteA.vcl
vcl.load siteB0 /etc/vinyl-cache/siteB.vcl
vcl.load siteC0 /etc/vinyl-cache/siteC.vcl
vcl.label siteA siteA0
vcl.label siteB siteB0
vcl.label siteC siteC0
vcl.load main /etc/vinyl-cache/main.vcl
vcl.use main

هر خط در فایل، از جمله خط پایانی، باید با یک سطر تازه (newline) یا بازگشت به ابتدای سطر (carriage return) پایان یابد، در غیر این صورت ناقص در نظر گرفته می‌شود که یک خطای مهلک (fatal error) است.

اگر دستوری در فایل با پیشوند '-' مشخص شده باشد، شکست در اجرای آن مانع از راه‌اندازی نخواهد شد.

توجه داشته باشید که هنگام تکیه بر فایل دستورهای CLI برای بارگذاری پیکربندی‌ها در زمان راه‌اندازی، درج یک دستور صریح vcl.use جهت انتخاب این‌که کدام VCL باید VCL فعال باشد، الزامی است.

واحدهای پارامترهای زمان اجرا

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

bool

یک پارامتر بولی مقادیر on و off را می‌پذیرد.

این پارامتر مقادیر زیر را نیز شناسایی می‌کند:

bytes

یک پارامتر bytes به یکی از پسوندهای واحدهای زیر نیاز دارد:

واحدهای ضریب را می‌توان با یک b اضافی ضمیمه کرد. برای نمونه 32k معادل 32kb است. واحدهای بایت به بزرگی یا کوچکی حروف حساس نیستند (case-insensitive)..SS ثانیه‌ها (seconds)

یک پارامتر مدت‌زمان (duration) می‌تواند پسوندهای یکای زیر را بپذیرد:

اگر پارامتر از نوع مهلت زمانی (timeout) یا موعد (deadline) باشد، مقدار "never" (در صورت مجاز بودن) تأثیر پارامتر را غیرفعال می‌کند.

پرچم‌های پارامترهای زمان اجرا (Run Time Parameter Flags)

پارامترهای زمان اجرا با پرچم‌های اختصاری مشخص شده‌اند تا از تکرار چندبارهٔ متن یکسان در جدول زیر جلوگیری شود. معنای این پرچم‌ها به شرح زیر است:

استثنائات مقادیر پیش‌فرض در سیستم‌های ۳۲ بیتی (Default Value Exceptions on 32 bit Systems)

توجه داشته باشید که در سیستم‌های ۳۲ بیتی، به‌منظور صرفه‌جویی در فضای حافظهٔ مجازی (VM)، برخی مقادیر پیش‌فرض یا بیشینه نسبت به مقادیر فهرست‌شده در زیر کاهش یافته‌اند:

accept_filter

نکته: این پارامتر به قابلیتی وابسته است که در همهٔ پلتفرم‌ها در دسترس نیست.

فعال‌سازی accept-filterهای هسته. در صورت فعال بودن، ممکن است برای اعمال اثر نیاز به بارگذاری یک ماژول هسته باشد.

فعال کردن accept_filter ممکن است در وهلهٔ اول از رسیدن برخی درخواست‌ها به Vinyl Cache جلوگیری کند. درخواست‌های بدریخت (malformed) ممکن است شناسایی‌نشده باقی بمانند و شمارندهٔ client_req_400 را افزایش ندهند. درخواست‌های GET یا HEAD دارای بدنه ممکن است به‌طور کامل مسدود شوند.

acceptor_sleep_decay

اگر با کمبود منابعی مانند توصیف‌کننده‌های فایل (file descriptors) یا worker threadها مواجه شویم، acceptor بین پذیرش‌ها به خواب می‌رود. این پارامتر مدت‌زمان خواب را به ازای هر پذیرش موفق (به‌طور ضربی) کاهش می‌دهد (یعنی: 0.9 = ۱۰٪ کاهش).

acceptor_sleep_incr

اگر با کمبود منابعی مانند توصیف‌کننده‌های فایل یا worker threadها مواجه شویم، acceptor بین پذیرش‌ها به خواب می‌رود. این پارامتر کنترل می‌کند که با هر بار شکست در پذیرش یک اتصال جدید، چه میزان به مدت‌زمان خواب اضافه شود.

acceptor_sleep_max

اگر با کمبود منابعی مانند توصیف‌کننده‌های فایل یا worker threadها مواجه شویم، acceptor بین پذیرش‌ها به خواب می‌رود. این پارامتر حداکثر مدت‌زمانی را که می‌تواند بین تلاش‌ها برای پذیرش اتصالات جدید بخوابد، محدود می‌کند..SS auto_restart

راه‌اندازی مجدد خودکار فرایند فرزند/کارگر (child/worker) در صورت از کار افتادن آن.

backend_idle_timeout

مدت‌زمان انتظار (تایم‌اوت) پیش از بستن اتصالات بدون استفادهٔ backend.

backend_local_error_holddown

هنگام برقراری اتصال به backendها، برخی کدهای خطا (EADDRNOTAVAIL, EACCESS, EPERM) نشان‌دهندهٔ کمبود منابع محلی یا مشکل در پیکربندی هستند که تلاش مجدد برای برقراری اتصال ممکن است به دلیل پیچیدگی عملیات‌های مربوطه در هسته (kernel)، شرایط را بدتر کند. این پارامتر از تلاش‌های مکرر برای برقراری اتصال به مدت‌زمان تعیین‌شده جلوگیری می‌کند.

backend_remote_error_holddown

هنگام برقراری اتصال به backendها، برخی کدهای خطا (ECONNREFUSED, ENETUNREACH) نشان‌دهندهٔ مشکلات اساسی در اتصال هستند، مانند نپذیرفتن اتصالات توسط backend یا مشکلات مسیریابی، که در چنین شرایطی تلاش‌های مکرر برای برقراری اتصال بی‌فایده تلقی می‌شود. این پارامتر از تلاش‌های مکرر برای برقراری اتصال به مدت‌زمان تعیین‌شده جلوگیری می‌کند.

backend_wait_limit

حداکثر تعداد تراکنش‌هایی که می‌توانند در صف انتظار برای در دسترس قرار گرفتن یک اتصال backend قرار گیرند. این مقدار پیش‌فرض 0 (صفر) به این معنی است که هیچ صفی برای تراکنش‌ها تشکیل نمی‌شود. VCL می‌تواند این مقدار پیش‌فرض را برای هر backend بازنویسی (override) کند.

توجه داشته باشید که از این قابلیت باید با احتیاط استفاده شود، چرا که می‌تواند موجب انباشته شدن ریسه‌ها (threads) و افزایش زمان پاسخ‌دهی شود..SS backend_wait_timeout

هنگامی که یک backend هیچ اتصال آزادی برای یک تراکنش ندارد، تراکنش می‌تواند در صف قرار گیرد (به backend_wait_limit مراجعه کنید) تا منتظر اتصال بماند. این مدت‌زمان پیش‌فرضی است که تراکنش پیش از انصراف منتظر خواهد ماند. VCL می‌تواند این مقدار پیش‌فرض را برای هر backend بازنویسی کند.

اکیداً توصیه می‌شود که این مقدار هرگز بیش از چند ثانیه تنظیم نشود.

ban_any_variant

حداکثر تعداد گونه‌های (variants) احتمالاً ناسازگار که در حین جستجو (lookup) در برابر فهرست ban ارزیابی می‌شوند. تنظیم این مقدار روی 0 به این معنی است که تنها گونه‌های منطبق در برابر فهرست ban کنونی ارزیابی خواهند شد.

ban_cutoff

محتوای دنباله طولانی (long tail) را از حافظه پنهان پاکسازی می‌کند تا تعداد banها زیر این مقدار باقی بماند. مقدار 0 آن را غیرفعال می‌کند.

هنگامی که این پارامتر روی مقداری غیر از صفر تنظیم شود، ban lurker طبق معمول به بررسی فهرست ban از بالا به پایین ادامه می‌دهد، اما هنگامی که به ban شماره ban_cutoff برسد، با تمام اشیاء طوری رفتار می‌کند که گویی با یک ban منطبق شده‌اند و آن‌ها را از حافظه پنهان پاکسازی می‌کند. از آنجا که اشیاء فعالانه استفاده‌شده در زمان درخواست در برابر فهرست ban آزمایش می‌شوند و بنابراین احتمالاً با banهای نزدیک به بالای فهرست مرتبط هستند، با ban_cutoff، اشیائی که کمتر مورد دسترسی قرار گرفته‌اند ("long tail") حذف می‌شوند.

این پارامتر یک شبکه ایمنی برای جلوگیری از زمان‌های پاسخ‌دهی نامطلوب ناشی از آزمایش banها در زمان جستجو (lookup) است. تنظیم یک cutoff، زمان پاسخ‌دهی بهتر را با کارایی حافظه پنهان مبادله می‌کند. مقدار توصیه‌شده متناسب با rate(bans_lurker_tests_tested) / n_objects در حین کارکرد ban lurker است که بیانگر تعداد banهایی است که سیستم توان تحمل آن را دارد. تاخیر اضافی ناشی از آزمایش ban در زمان درخواست، از مرتبه ban_cutoff / rate(bans_lurker_tests_tested) است. به عنوان مثال، برای rate(bans_lurker_tests_tested) = 2M/s و تاخیر قابل تحمل 100 میلی‌ثانیه، یک مقدار مناسب برای ban_cutoff ممکن است 200K باشد.

ban_dups

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

ban_lurker_age

فرآیند ban lurker، تا زمانی که banها به این سن نرسند آن‌ها را نادیده خواهد گرفت. هنگامی که یک ban اضافه می‌شود، ترافیک فعال به عنوان بخشی از جستجوی شیء در برابر آن آزمایش می‌شود. از آنجا که بسیاری از برنامه‌ها banها را به صورت انفجاری صادر می‌کنند، این پارامتر ban-lurker را تا پایان یافتن هجوم اولیه متوقف نگه می‌دارد. این مقدار باید روی زمان تقریبی طول کشیدن یک انفجار ban تنظیم شود..SS ban_lurker_batch

فرایند ban lurker پس از بررسی این تعداد شیء، به مدت ${ban_lurker_sleep} به خواب می‌رود. اگر ban-lurker منابع زیادی مصرف می‌کند، از این گزینه برای تنظیم آهنگ آن استفاده کنید.

ban_lurker_holdoff

مدت زمانی که ban lurker هنگام کناره‌گیری به نفع جستجو (lookup) به دلیل تداخل قفل‌ها (lock contention)، به خواب می‌رود.

ban_lurker_sleep

مدت زمانی که ban lurker پس از بررسی ${ban_lurker_batch} شیء به خواب می‌رود. اگر ban-lurker منابع زیادی مصرف می‌کند، از این مقدار برای تنظیم آهنگ آن استفاده کنید. مقدار صفر فرایند ban lurker را به‌طور کامل غیرفعال می‌کند.

between_bytes_timeout

پیش از انصراف از واکشی (fetch)، تنها به این میزان ثانیه بین بایت‌های دریافتی از backend منتظر می‌مانیم. مقادیر VCL به‌ازای هر backend یا به‌ازای هر درخواست backend اولویت دارند. این پارامتر برای درخواست‌های pipe'شده اعمال نمی‌شود.

cc_command

توجه: مقدار پیش‌فرض واقعی این پارامتر به محیط ساخت و گزینه‌های کامپایل Vinyl Cache بستگی دارد.

دستوری که برای کامپایل کد منبع C به یک شیء قابل بارگذاری توسط dlopen(3) استفاده می‌شود. بسط‌های زیر قابل استفاده هستند:

توالی‌های بسط درصد ناشناخته نادیده گرفته می‌شوند، و برای جلوگیری از ناسازگاری‌های آتی، نویسه‌های درصد باید با یک توالی درصد دوگانه گریز (escape) داده شوند.

بسط‌های %d و %D امکان ارسال مقدار پیش‌فرض پارامتر به یک اسکریپت پوششی (wrapper) جهت انجام پردازش‌های اضافی را فراهم می‌کنند..SS cc_warnings

توجه: مقدار پیش‌فرض واقعی این پارامتر به محیط ساخت و گزینه‌های Vinyl Cache بستگی دارد.

هشدارهایی که هنگام کامپایل کد منبع C با پارامتر cc_command استفاده می‌شوند. به‌طور پیش‌فرض، VCL با همان مجموعه هشدارهایی کامپایل می‌شود که خود Vinyl Cache با آن‌ها کامپایل شده است.

cli_limit

بیشینه اندازه پاسخ CLI. اگر پاسخ از این حد فراتر رود، کد وضعیت پاسخ به‌جای 200 برابر با 201 خواهد بود و خط آخر نشان‌دهنده کوتاه شدن (truncation) پاسخ خواهد بود.

cli_timeout

مهلت زمانی برای پاسخ‌های فرآیند فرزند به درخواست‌های CLI.

clock_skew

میزان اختلاف ساعت (clock skew) قابل‌پذیرش میان backend و ساعت محلی سیستم.

clock_step

میزان پرش یا تغییر ناگهانی ساعت (clock step) مشاهده‌شده‌ای که پیش از بروز وحشت سیستم (panic)، مایل به پذیرش آن هستیم.

connect_timeout

مهلت زمانی پیش‌فرض اتصال برای ارتباط‌های backend. تلاش برای اتصال به backend پیش از صرف‌نظر کردن، تنها به اندازه این مقدار ثانیه صورت می‌پذیرد. VCL می‌تواند این مقدار پیش‌فرض را برای هر backend و هر درخواست backend بازنویسی (override) کند..SS critbit_cooloff

مدت زمانی که درهم‌ساز critbit ساختارهای objhead حذف‌شده را در فهرست cooloff نگه می‌دارد.

debug

فعال/غیرفعال کردن انواع مختلف اشکال‌زدایی.

از پیشوند +/- برای تنظیم/بازنشانی بیت‌های تکی استفاده کنید:

default_keep

دوره نگهداری (keep) پیش‌فرض. یک شیء بدون‌استفاده تا این مدت نگهداری خواهد شد تا برای واکشی‌های شرطی backend در دسترس باشد. این بدان معناست که شیء در پایان ttl+grace+keep از حافظه پنهان (cache) حذف خواهد شد.

default_ttl

مقدار TTL اختصاص‌یافته به اشیاء در صورتی که نه backend و نه کد VCL مقداری برای آن تعیین نکرده باشند.

experimental

فعال/غیرفعال‌سازی ویژگی‌های آزمایشی.

برای تنظیم/بازنشانی بیت‌های مجزا از پیشوند +/- استفاده کنید:

fetch_chunksize

اندازه پیش‌فرض تکه‌ها (chunksize) که توسط fetcher استفاده می‌شود. این مقدار باید از اندازه اکثر اشیاء با TTL کوتاه بزرگ‌تر باشد. محدودیت‌های درونی در پیمانه storage_file افزایش این مقدار به فراتر از 128kb را به ایده‌ای تردیدبرانگیز تبدیل می‌کند..SS fetch_maxchunksize

حداکثر اندازه تکه‌ای (chunksize) که تلاش می‌شود از فضای ذخیره‌سازی تخصیص یابد. بیش از حد بزرگ بودن این مقدار ممکن است موجب ایجاد تأخیر و پراکندگی (fragmentation) در فضای ذخیره‌سازی شود.

first_byte_timeout

مهلت زمانی (timeout) پیش‌فرض برای دریافت نخستین بایت از backend. پیش از انصراف، تنها به مدت این تعداد ثانیه برای دریافت اولین بایت صبر می‌شود. دستورهای VCL می‌توانند این مقدار پیش‌فرض را برای هر backend و هر درخواست backend بازنویسی کنند. این پارامتر بر روی درخواست‌های pipe‌شده اعمال نمی‌شود.

gzip_buffer

اندازه بافر malloc استفاده‌شده برای پردازش gzip. اندازه بافر استفاده‌شده برای پردازش gzip. این بافرها برای داده‌های در حال انتقال (in-transit) استفاده می‌شوند؛ به عنوان نمونه داده‌های gunzip‌شده‌ای که به سمت کلاینت ارسال می‌شوند. کوچک بودن بیش از حد این فضا منجر به سربار بیشتر، نوشتن‌های مکرر روی سوکت‌ها و غیره می‌شود؛ بیش از حد بزرگ بودن آن نیز احتمالاً تنها اتلاف حافظه خواهد بود. بافرهای Gzip از فضای ذخیره‌سازی Transient تخصیص می‌یابند.

gzip_level

سطح فشرده‌سازی Gzip: مقدار 0=اشکال‌زدایی (debug)، مقدار 1=سریع (fast)، مقدار 9=بهترین (best)

gzip_memlevel

سطح حافظه Gzip: مقدار 1=کند/کمترین فشرده‌سازی، 9=سریع/بیشترین فشرده‌سازی. میزان تأثیر بر حافظه به‌صورت 1=1k، 2=2k، ... 9=256k است..SS h2_header_table_size

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

مقدار این پارامتر، SETTINGS_HEADER_TABLE_SIZE را در فریم اولیهٔ SETTINGS که هنگام برقراری یک نشست HTTP2 جدید به کلاینت فرستاده می‌شود، تعیین می‌کند.

h2_initial_window_size

اندازهٔ اولیهٔ پنجرهٔ کنترل جریان HTTP2.

مقدار این پارامتر، SETTINGS_INITIAL_WINDOW_SIZE را در فریم اولیهٔ SETTINGS که هنگام برقراری یک نشست HTTP2 جدید به کلاینت فرستاده می‌شود، تعیین می‌کند.

h2_max_concurrent_streams

حداکثر تعداد جریان‌های (streams) هم‌روند HTTP2. این مقدار بیانگر تعداد درخواست‌هایی است که می‌توانند به‌طور هم‌زمان برای یک اتصال HTTP2 واحد فعال باشند.

مقدار این پارامتر، SETTINGS_MAX_CONCURRENT_STREAMS را در فریم اولیهٔ SETTINGS که هنگام برقراری یک نشست HTTP2 جدید به کلاینت فرستاده می‌شود، تعیین می‌کند.

h2_max_frame_size

حداکثر اندازهٔ بار مفید (payload) در هر فریم HTTP2 که مایل به پذیرش آن هستیم.

مقدار این پارامتر، SETTINGS_MAX_FRAME_SIZE را در فریم اولیهٔ SETTINGS که هنگام برقراری یک نشست HTTP2 جدید به کلاینت فرستاده می‌شود، تعیین می‌کند.

h2_max_header_list_size

حداکثر اندازهٔ یک فهرست هدر فشرده‌نشده در HTTP2. این پارامتر به SETTINGS_MAX_HEADER_LIST_SIZE در فریم اولیهٔ SETTINGS نگاشت نمی‌شود، بلکه به‌جای آن پارامتر http_req_size نگاشت می‌شود.

پارامتر http_req_size کلاینت‌های HTTP2 را از حداکثر اندازه برای فهرست هدر مطلع می‌سازد. فراتر رفتن از http_req_size به‌منظور حفظ اتصال منجر به بازنشانی جریان (reset stream) پس از پردازش بلوک HPACK می‌شود، اما فراتر رفتن از h2_max_header_list_size منجر به قطع فوری اتصال HTTP2 خواهد شد.

اگر h2_max_header_list_size کمتر از http_req_size باشد، هیچ تأثیری نخواهد داشت؛ به‌جز مقدار ویژهٔ صفر که به‌صورت ۱۵۰٪ از http_req_size تفسیر می‌شود..SS h2_rapid_reset

آستانه بالایی برای اینکه یک فریم RST_STREAM در http/2 چقدر سریع پس از یک فریم HEADERS تجزیه شود تا مشکوک در نظر گرفته شده و مشمول محدودیت‌های نرخ تعیین‌شده توسط h2_rapid_reset_limit و h2_rapid_reset_period گردد. تغییرات این پارامتر بر پیش‌فرض نشست‌های جدید HTTP2 اعمال می‌شود. می‌توان از vmod_h2(3) برای تنظیم آن از طریق VCL استفاده کرد.

h2_rapid_reset_limit

حد مجاز RST در HTTP2. حداکثر تعداد مجاز ریست‌های جریان صادرشده توسط کلاینت در طول یک بازه زمانی را پیش از بسته‌شدن اتصال مشخص می‌کند. تنظیم این پارامتر بر روی 0 محدودیت را غیرفعال می‌کند. تغییرات این پارامتر بر پیش‌فرض نشست‌های جدید HTTP2 اعمال می‌شود. می‌توان از vmod_h2(3) برای تنظیم آن از طریق VCL استفاده کرد.

h2_rapid_reset_period

مدت زمان پنجره لغزان HTTP2 برای h2_rapid_reset_limit. تغییرات این پارامتر بر پیش‌فرض نشست‌های جدید HTTP2 اعمال می‌شود. می‌توان از vmod_h2(3) برای تنظیم آن از طریق VCL استفاده کرد.

h2_rx_window_increment

افزایش‌های پنجره دریافت HTTP2. میزان اعتباری که در فریم‌های WINDOW_UPDATE ارسال می‌کنیم چقدر بزرگ باشد. تنها بر بدنه درخواست‌های ورودی تأثیر می‌گذارد (مانند: POST، PUT و غیره).

h2_rx_window_low_water

حد پایین پنجره دریافت HTTP2. تلاش می‌شود پنجره دست‌کم به این اندازه بزرگ نگه داشته شود. تنها بر بدنه درخواست‌های ورودی تأثیر می‌گذارد (مانند: POST، PUT و غیره)..SS h2_rxbuf_storage

نام backend ذخیره‌سازی که بافرهای دریافت HTTP/2 باید از آن تخصیص یابند.

h2_window_timeout

محدودیت زمانی HTTP2 بدون اعتبارات پنجره (window credits). مدت زمانی که یک جریان (stream) می‌تواند منتظر کلاینت بماند تا به پنجره اعتبار دهد و اجازه ارسال فریم‌های DATA بیشتری داده شود.

http1_iovs

تعداد بردار io (io vector) جهت تخصیص برای مخابره پروتکل HTTP1. یک هدر HTTP1 به ۷ + ۲ عدد به ازای هر فیلد هدر HTTP نیاز دارد. از workspace_thread تخصیص داده می‌شود. این پارامتر فقط بر بردار‌های io استفاده‌شده برای تحویل به کلاینت اثر می‌گذارد. برای واکشی‌های بک‌اند (backend fetches)، بیشترین تعداد بردار io (تا سقف IOV_MAX) از حافظه در دسترس workspace_thread تخصیص می‌یابد.

http_gzip_support

کلاینت‌هایی که از gzip پشتیبانی نمی‌کنند، هدر Accept-Encoding آن‌ها حذف خواهد شد. برای کسب اطلاعات بیشتر درباره نحوه پیاده‌سازی gzip، لطفاً فصل مربوط به gzip در راهنمای مرجع Vinyl Cache را ببینید.

هنگامی که پشتیبانی از gzip غیرفعال است، متغیرهای beresp.do_gzip و beresp.do_gunzip هیچ اثری در VCL ندارند.

http_max_hdr

بیشترین تعداد خطوط هدر HTTP که در {req|resp|bereq|beresp}.http مجاز می‌دانیم (اندازه obj.http به طور خودکار به تعداد دقیق هدرها تنظیم می‌شود). از نظر حافظه workspace بسیار کم‌هزینه است (~۲۰ بایت). توجه داشته باشید که خط اول به اندازه پنج خط هدر فضا اشغال می‌کند..SS http_range_support

فعال‌سازی پشتیبانی از هدرهای HTTP Range.

http_req_hdr_len

حداکثر طول مجاز برای هر یک از هدرهای درخواست کلاینت HTTP. این محدودیت شامل خطوط ادامه‌دار آن نیز می‌شود.

http_req_overflow_status

کد وضعیت HTTP که در صورت فراتر رفتن از http_req_size بازگردانده می‌شود. مقدار پیش‌فرض 0 اتصال را بدون ارسال هیچ پاسخ HTTP و به‌صورت خاموش می‌بندد. توجه داشته باشید که هیچ کد وضعیت استاندارد HTTP وجود ندارد که دقیقاً با پیاده‌سازی http_req_size مطابقت داشته باشد. کد 414 فقط برای URL اعمال می‌شود، در حالی که 413 برای بدنهٔ درخواست اعمال می‌گردد. کد 400 احتمالاً کم‌اشتباه‌ترین مقدار جایگزین در مقایسه با عدم ارسال هیچ پاسخی (0) است. همچنین می‌تواند به دلیل محدودیت‌های پیکربندی‌شده به‌عنوان یک خطای داخلی از سمت Vinyl Cache در نظر گرفته شود، بنابراین 500 نیز مجاز است.

http_req_size

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

برای کلاینت‌های HTTP2، این مقدار به‌صورت MAX_HEADER_LIST_SIZE در فریم اولیهٔ SETTINGS اعلان می‌شود.

http_resp_hdr_len

حداکثر طول مجاز برای هر یک از هدرهای پاسخ backend HTTP. این محدودیت شامل خطوط ادامه‌دار آن نیز می‌شود.

http_resp_size

حداکثر تعداد بایت‌های پاسخ backend HTTP که پردازش خواهد شد. این محدودیت شامل تمام بایت‌ها تا خط خالی دوگانه‌ای است که به پاسخ HTTP پایان می‌دهد. حافظه برای پاسخ از فضای کاری backend (پارامتر: workspace_backend) تخصیص می‌یابد و این پارامتر مشخص می‌کند که پاسخ مجاز است چه مقدار از آن را اشغال کند..SS idle_send_timeout

مهلت زمانی ارسال برای تکه‌های مجزای داده در اتصالات کلاینت. در صورت اعمال 'send_timeout' ممکن است افزایش یابد.

هنگامی که این مهلت زمانی به سر رسد، نشست بسته می‌شود.

برای اطلاعات بیشتر، به صفحهٔ راهنمای setsockopt(2) یا socket(7) ذیل SO_SNDTIMEO مراجعه کنید.

listen_depth

عمق صف شنود (listen).

lru_interval

مهلت زمانی پیش از جابه‌جایی شیء در فهرست LRU. اشیاء تنها در صورتی به ابتدای فهرست LRU منتقل می‌شوند که در طول این بازهٔ زمانی از قبل به آنجا منتقل نشده باشند. این کار تعداد عملیات‌های قفل‌گذاری لازم برای دسترسی به فهرست LRU را کاهش می‌دهد.

max_esi_depth

حداکثر عمق پردازش esi:include.

max_restarts

حد بالای تعداد دفعاتی که یک درخواست می‌تواند مجدداً راه‌اندازی شود..SS max_retries

حداکثر تعداد دفعاتی که یک واکشی backend می‌تواند مجدداً تلاش کند.

max_vcl

آستانه برنامه‌های بارگذاری‌شده VCL. (برچسب‌های VCL شمارش نمی‌شوند.) پارامتر max_vcl_handling رفتار را مشخص می‌کند.

max_vcl_handling

رفتار هنگام تلاش برای فراتر رفتن از حد مجاز VCLهای بارگذاری‌شده در max_vcl.

nuke_limit

حداکثر تعداد اشیایی که برای باز کردن فضا جهت بدنه یک شیء، برای حذف (nuke) آن‌ها تلاش می‌شود.

panic_buffer

اندازه بافر پیام‌های panic. بافر panic در دایرکتوری کاری به‌عنوان حافظه مشترک بین فرایندهای management و worker تخصیص داده می‌شود، بنابراین در صورت تغییر این مقدار، باید فضای کافی در دایرکتوری کاری در نظر گرفته شود. پیام‌های panic به اندازه پیکربندی‌شده کوتاه (truncate) می‌شوند..SS pcre2_depth_limit

سقف عمق بازگشت برای منطق تطبیق داخلی در یک pcre2_match().

(ببینید: pcre2_set_depth_limit() در مستندات pcre2.)

این گزینه یک حد بالایی برای مقدار پشتهٔ (stack) استفاده‌شده توسط PCRE2 برای دسته‌های خاصی از عبارت‌های منظم تعیین می‌کند.

ما مقدار پیش‌فرض را برای جلوگیری از فروپاشی برنامه (crash)، به قیمت خطاهای احتمالی در تطبیق عبارت‌های منظم، پایین تنظیم کرده‌ایم.

شکست‌های تطبیق در گزارش‌ها به عنوان پیام‌های VCL_Error ثبت خواهند شد.

pcre2_jit_compilation

استفاده از کامپایلر JIT برای pcre2 در صورت در دسترس بودن.

pcre2_match_limit

محدودیت تعداد فراخوانی‌ها برای منطق تطبیق داخلی در pcre2_match().

(ببینید: pcre2_set_match_limit() در مستندات pcre2.)

این پارامتر میزان زمان پردازنده‌ای (CPU) را که تطبیق عبارت منظم می‌تواند مصرف کند، محدود می‌سازد.

ping_interval

بازهٔ زمانی بین پینگ‌ها از والد (parent) به فرزند (child). مقدار صفر پینگ‌زدن را به طور کامل غیرفعال می‌کند که امکان متصل کردن یک اشکال‌زدا (debugger) به فرزند را فراهم می‌سازد.

pipe_sess_max

حداکثر تعداد نشست‌های اختصاص‌یافته به تراکنش‌های pipe..SS pipe_task_deadline

ضرب‌الاجل برای نشست‌های PIPE. صرف‌نظر از وجود هرگونه فعالیت در هر یک از دو جهت، پس از این تعداد ثانیه نشست بسته می‌شود.

pipe_timeout

مهلت بیکاری برای نشست‌های PIPE. اگر به مدت این تعداد ثانیه هیچ داده‌ای در هیچ‌یک از دو جهت دریافت نشود، نشست بسته می‌شود.

pool_req

پارامترها برای استخر حافظه درخواست به ازای هر worker pool.

این سه عدد عبارتند از:

pool_sess

پارامترها برای استخر حافظه نشست به ازای هر worker pool.

این سه عدد عبارتند از:

prefer_ipv6

ترجیح دادن نشانی IPv6 هنگام اتصال به بک‌اندهایی که هم نشانی IPv4 و هم IPv6 دارند.

rush_exponent

تعداد درخواست‌های پارک‌شده‌ای که به ازای هر درخواست تکمیل‌شده روی شیء آغاز می‌کنیم. نکته: حتی با وجود تأخیر ضمنی در تحویل، این پارامتر افزایش نمایی تعداد ریسه‌های کارگر (worker threads) را کنترل می‌کند. مقدار 1 در عوض ازسرگیری درخواست‌ها را متوالی (ترتیبی) می‌کند و تنها برای مقاصد آزمایشی مفید است.

send_timeout

کل مهلت زمانی (timeout) برای پاسخ‌های معمولی HTTP1. این مقدار برای برخی خطاهای تولیدشده به‌صورت داخلی و حالت pipe اعمال نمی‌شود.

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

هنگامی که این مهلت زمانی به پایان برسد، نشست بسته می‌شود..SS shortlived

اشیایی که با (ttl+grace+keep) کوتاه‌تر از این مقدار ایجاد شوند، همواره در فضای ذخیره‌سازی گذرا (transient storage) قرار می‌گیرند.

sigsegv_handler

نصب یک گردانندهٔ سیگنال که هنگام بروز خطاهای تقسیم‌بندی (segmentation fault)، خطاهای گذرگاه (bus error) و سیگنال‌های abort، تلاش می‌کند اطلاعات اشکال‌زدایی را تخلیه کند.

startup_timeout

مهلت زمانی جایگزین برای راه‌اندازی اولیهٔ فرایند کارگر (worker process). اگر cli_timeout طولانی‌تر از startup_timeout باشد، به جای آن استفاده می‌شود.

syslog_cli_traffic

ثبت تمام ترافیک CLI در syslog(LOG_INFO).

tcp_fastopen

توجه: این پارامتر به قابلیتی وابسته است که در همهٔ بسترها در دسترس نیست.

فعال‌سازی افزونهٔ TCP Fast Open.

tcp_keepalive_intvl

توجه: این پارامتر به قابلیتی وابسته است که در همهٔ بسترها در دسترس نیست.

تعداد ثانیه‌های بین کاوش‌های TCP keep-alive. این مقدار برای سوکت‌های دامنه یونیکس (Unix domain sockets) نادیده گرفته می‌شود..SS tcp_keepalive_probes

نکته: این پارامتر به قابلیتی وابسته است که در همهٔ پلتفرم‌ها در دسترس نیست.

بیشترین تعداد کاوش‌های TCP keep-alive برای ارسال، پیش از قطع امید و بستن اتصال در صورتی که هیچ پاسخی از طرف مقابل دریافت نشود. برای سوکت‌های دامنه یونیکس نادیده گرفته می‌شود.

tcp_keepalive_time

نکته: این پارامتر به قابلیتی وابسته است که در همهٔ پلتفرم‌ها در دسترس نیست.

تعداد ثانیه‌هایی که یک اتصال باید در وضعیت بیکار (idle) باشد پیش از آن‌که TCP شروع به ارسال کاوش‌های keep-alive کند. برای سوکت‌های دامنه یونیکس نادیده گرفته می‌شود.

thread_pool_add_delay

حداقل به این میزان پس از ایجاد یک نخ (thread) درنگ کنید.

برخی سیستم‌های (دارای باگ) ممکن است به تأخیری کوتاه (کسری از ثانیه) بین ایجاد نخ‌ها نیاز داشته باشند. اگر مشاهده کردید که شمارندهٔ 'threads_failed' بیش از حد رشد می‌کند، این مقدار را روی چند میلی‌ثانیه تنظیم کنید.

تنظیم بیش از اندازهٔ این مقدار منجر به ناکافی بودن نخ‌های کارگر (worker threads) می‌شود.

thread_pool_destroy_delay

به این میزان پس از نابودی یک نخ (thread) درنگ کنید.

این پارامتر کاهش تدریجی استخرهای نخ (thread pools) را در هنگام بیکاری (یا شرایط شبه‌بیکاری) کنترل می‌کند..SS thread_pool_fail_delay

پس از هر بار شکست در ایجاد thread، پیش از تلاش برای ایجاد یک thread دیگر، حداقل به این میزان صبر کنید.

شکست در ایجاد یک thread کارگر (worker thread) اغلب نشانه‌ای از رو به پایان بودن کار است، چرا که منابع فرآیند در حال اتمام است. این تاخیر تلاش می‌کند تا بی‌جهت رسیدن به پایان کار را تسریع نکند.

اگر شکست در ایجاد threadها به یک مشکل تبدیل شده است، بررسی کنید که مقدار thread_pool_max بیش از حد بالا نباشد.

همچنین افزایش مقادیر thread_pool_timeout و thread_pool_min ممکن است به کاهش نرخ نابودی threadها و ایجاد مجدد آن‌ها کمک کند.

thread_pool_max

حداکثر تعداد threadهای کارگر در هر استخر (pool).

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

thread_pool_min

حداقل تعداد threadهای کارگر در هر استخر.

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

حداقل مقدار از نظر فنی ۵ thread است، اما اکیداً توصیه می‌شود که این پارامتر حداقل روی ۱۰ تنظیم شود.

thread_pool_reserve

تعداد threadهای کارگر رزرو شده برای وظایف حیاتی در هر استخر.

وظایف ممکن است برای تکمیل شدن به وظایف دیگری نیاز داشته باشند (برای مثال، درخواست‌های client ممکن است به درخواست‌های backend نیاز داشته باشند؛ نشست‌های http2 نیازمند streamها هستند که آن‌ها نیز به درخواست‌ها وابسته می‌باشند). این سهمیهٔ رزرو به این منظور است که اطمینان حاصل شود وظایف با اولویت پایین‌تر حتی تحت بار زیاد نیز مانع از اجرای وظایف با اولویت بالاتر نمی‌شوند.

مقدار مؤثر، صرف‌نظر از مقدار این پارامتر، حداقل ۵ (تعداد کلاس‌های اولویت داخلی) است..SS thread_pool_stack

اندازه پشته ریسه کارگر. این مقدار احتمالاً توسط هسته به مضربی از 4k (یا هر مقداری که page_size باشد) به بالا گرد می‌شود.

اندازه پشته مورد نیاز در درجه اول تحت تأثیر عمق call-tree است. متداول‌ترین عوامل تعیین‌کننده مرتبط در کد هسته Vinyl Cache عبارتند از فشرده‌سازی/خروج از فشرده‌سازی GZIP، پردازش ESI و تطابق عبارات باقاعده (regular expression). همچنین VMODها ممکن است به مقادیر قابل توجهی پشته اضافی نیاز داشته باشند. عمق تودرتویی زیرروال‌های VCL عامل دیگری است، اگرچه معمولاً غالب نیست.

اندازه پشته به ازای هر ریسه است، بنابراین حداکثر کل حافظه مورد نیاز برای پشته‌های ریسه کارگر در مرتبه size = thread_pools x thread_pool_max x thread_pool_stack خواهد بود.

بنابراین، به‌ویژه برای پیکربندی‌هایی با ریسه‌های بسیار، نگه داشتن اندازه پشته در کمترین مقدار به کاهش میزان حافظه مورد نیاز Vinyl Cache کمک می‌کند.

از سوی دیگر، thread_pool_stack تحت هر شرایطی باید به اندازه کافی بزرگ باشد، در غیر این صورت Vinyl Cache به دلیل سرریز پشته (stack overflow) از کار خواهد افتاد. معمولاً سرریز پشته به صورت خطای بخش‌بندی (segfault / SIGSEGV) ظاهر می‌شود که در آن نشانی خطا نزدیک به اشاره‌گر پشته (sp) است.

مگر اینکه مصرف پشته کاهش یابد، در هنگام رخ دادن سرریز پشته باید مقدار thread_pool_stack افزایش یابد. توصیه می‌شود افزایش آن در گام‌های 150%-200% صورت گیرد تا زمانی که وقوع سرریز پشته متوقف شود.

thread_pool_timeout

آستانه بیکاری ریسه.

ریسه‌های مازاد بر thread_pool_min که حداقل به این مدت زمان بیکار بوده‌اند، از بین خواهند رفت.

thread_pool_watchdog

ناظر (watchdog) گیر کردن صف ریسه‌ها.

اگر برای این مدت زمان هیچ کار در صف قرار گرفته‌ای آزاد نشود، فرایند کارگر خود را دچار panic می‌کند.

thread_pools

تعداد استخرهای ریسه کارگر.

افزایش تعداد استخرهای کارگر، رقابت بر سر قفل (lock contention) را کاهش می‌دهد. هر استخر کارگر همچنین دارای یک ریسه برای پذیرش اتصالات جدید است، بنابراین برای نرخ‌های بسیار بالای اتصالات جدید ورودی در سیستم‌هایی با هسته‌های پرشمار، ممکن است افزایش استخرهای کارگر ضروری باشد.

تعداد بیش از حد استخرها منابع CPU و RAM را هدر می‌دهد، و اختصاص بیش از یک استخر به ازای هر CPU به احتمال زیاد به کارایی آسیب می‌زند.

می‌توان آن را به‌صورت زنده (on the fly) افزایش داد، اما کاهش آن برای اعمال شدن نیازمند راه‌اندازی مجدد است، مگر اینکه پرچم اشکال‌زدایی آزمایشی drop_pools تنظیم شده باشد..SS thread_queue_limit

طول مجاز صف درخواست به ازای هر thread-pool.

این پارامتر تعداد درخواست‌هایی را تعیین می‌کند که در انتظار یک ریسهٔ آزاد در صف قرار می‌گیرند. فراتر از این محدودیت، نشست‌ها به جای قرار گرفتن در صف، دور انداخته (drop) می‌شوند.

thread_stats_rate

ریسه‌های کارگر (worker threads) آمارها را جمع‌آوری می‌کنند و در صورتی که پس از اتمام یک وظیفه (درخواست/واکشی و غیره) قفل آزاد باشد، آن‌ها را در شمارنده‌های آمار سراسری تخلیه می‌نمایند. این پارامتر حداکثر تعداد وظایفی را تعیین می‌کند که یک ریسهٔ کارگر می‌تواند پیش از اجبار به تخلیهٔ آمارهای انباشته‌شده‌اش در شمارنده‌های سراسری، انجام دهد.

timeout_idle

مهلت زمانی بی‌کاری (idle timeout) برای اتصالات کلاینت.

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

این پارامتر به‌ویژه برای اتصالات keepalive پروتکل HTTP1 کاربرد دارد که در صورت عدم دریافت درخواست بعدی پیش از به پایان رسیدن این مهلت زمانی، بسته می‌شوند.

timeout_linger

مدت زمانی که ریسهٔ کارگر روی یک نشست بی‌کار درنگ می‌کند، پیش از آنکه آن را به waiter تحویل دهد. هنگامی که نشست‌ها مجدداً استفاده می‌شوند، تا نیمی از کل موارد استفادهٔ مجدد در طول ۱۰۰ میلی‌ثانیه نخست پس از تکمیل درخواست قبلی رخ می‌دهند. تنظیم بیش از حد بالای این پارامتر باعث می‌شود ریسه‌های کارگر بدون انجام کاری بیهوده معطل بمانند، و تنظیم بسیار پایین آن تنها به این معناست که نشست‌های بیشتری از مسیر غیرمستقیم waiter عبور می‌کنند.

transit_buffer

تعداد بایت‌هایی که Vinyl Cache برای واکشی‌های جریانیِ غیرقابل‌کَش از backend بافر می‌کند - به عبارت دیگر، Vinyl Cache چند بایت جلوتر از آنچه به کلاینت فرستاده شده را از backend می‌خواند. مقدار صفر به معنی عدم وجود محدودیت است و شیء تا حد امکان با بیشترین سرعت واکشی می‌شود.

در هنگام مواجهه با کلاینت‌های کُند، تنظیم این پارامتر روی مقداری غیر از صفر می‌تواند از ذخیرهٔ کامل اشیاء بزرگ غیرقابل‌کَش جلوگیری کند؛ به‌ویژه در شرایطی که هدف تنها پخش جریانی (stream) آن‌ها به کلاینت است. در نتیجه، تراکنش یک کلاینت کُند، اتصال backend را تا پایان تحویل باز نگه می‌دارد.

این پارامتر مقدار پیش‌فرض متغیر VCL با نام beresp.transit_buffer است که می‌تواند برای کنترل بافر عبوری (transit buffer) به ازای هر درخواست به backend استفاده شود..SS uncacheable_ttl

مقدار TTL تخصیص‌یافته به اشیاء غیرقابل‌کَش توسط VCL توکار.

vary_notice

تعداد گونه‌هایی که باید ارزیابی شوند تا یک اعلان (Notice) مبنی بر احتمال وجود بیش از حد گونه‌ها ثبت شود.

vcc_allow_inline_c

نام مستعار منسوخ‌شده برای پارامتر vcc_feature.

vcc_err_unref

نام مستعار منسوخ‌شده برای پارامتر vcc_feature.

vcc_feature

فعال یا غیرفعال کردن رفتارهای گوناگون VCC.

برای فعال یا غیرفعال کردن رفتارهای مجزا از پیشوند +/- استفاده کنید:

vcc_unsafe_path

نام مستعار منسوخ‌شده برای پارامتر vcc_feature..SS vcl_cooldown

مدت‌زمانی که یک VCL پس از جایگزین شدن به عنوان VCL فعال، گرم نگه داشته می‌شود (تفکیک‌پذیری زمانی تقریباً ۳۰ ثانیه).

vcl_path

نکته: مقدار پیش‌فرض واقعی این پارامتر به محیط و گزینه‌های ساخت Vinyl Cache بستگی دارد.

دایرکتوری (یا فهرستی از دایرکتوری‌ها که با دونقطه از هم جدا شده‌اند) که نام‌های نسبی فایل‌های VCL (دستورهای vcl.load و include) در آن‌ها جستجو می‌شوند. به‌طور پیش‌فرض، Vinyl Cache فایل‌های VCL را هم در دایرکتوری پیکربندی سیستم و هم در دایرکتوری داده‌های اشتراکی جستجو می‌کند تا بسته‌ها بتوانند فایل‌های VCL خود را در مکانی استاندارد قرار دهند که includeهای نسبی در آن کار کنند. مواردی که با +glob فراخوانی (include) می‌شوند را نمی‌توان در vcl_path جستجو کرد.

vmod_path

نکته: مقدار پیش‌فرض واقعی این پارامتر به محیط و گزینه‌های ساخت Vinyl Cache بستگی دارد.

دایرکتوری (یا فهرستی از دایرکتوری‌ها که با دونقطه از هم جدا شده‌اند) که VMODها در آن قرار دارند.

vsl_buffer

تعداد بایت‌های فضای کاری (req-/backend-) اختصاص‌یافته برای بافر کردن رکوردهای VSL. هنگامی که این پارامتر تنظیم می‌شود، به احتمال زیاد workspace_client و workspace_backend نیز باید به همان میزان تنظیم شوند.

تنظیم این مقدار روی عددی بیش از حد بالا موجب مصرف زیاد حافظه می‌شود؛ تنظیم بیش از حد پایین آن باعث تخلیه (flush) مکرر VSL و احتمالاً افزایش رقابت بر سر قفل (lock-contention) در mutex مربوط به VSL خواهد شد.

vsl_mask

ماسک کردن پیام‌های منفرد VSL برای جلوگیری از ثبت آن‌ها در گزارش‌ها.

برای لغو ماسک یا ماسک کردن پیام‌های منفرد VSL، از پیشوند +/- پیش از نام برچسب VSL استفاده کنید. برای مقادیر مجاز vsl(7) را ببینید..SS vsl_reclen

حداکثر تعداد بایت‌ها در یک رکورد لاگ SHM.

vsl_space

میزان فضای تخصیص‌یافته برای بافرِ fifo مربوط به VSL در قطعه حافظهٔ VSM. اگر این مقدار را بیش از حد کوچک تعیین کنید، vinyl{ncsa|log} و غیره قادر به همگام ماندن نخواهند بود. بزرگ در نظر گرفتن بیش از حد آن نیز صرفاً منابع حافظه را هدر می‌دهد.

vsm_free_cooldown

مدت زمانی که حافظهٔ VSM پس از آزادسازی، گرم (آماده استفاده) نگه داشته می‌شود (دقت تفکیک تقریباً ۲ ثانیه).

workspace_backend

میزان فضای کاری پروتکل HTTP به بایت برای req/resp در backend HTTP. اگر بزرگ‌تر از 4k است، برای بهره‌وری حافظه مجازی (VM) از مضربی از 4k استفاده کنید.

workspace_client

میزان فضای کاری پروتکل HTTP به بایت برای req/resp کلاینت‌های HTTP. برای بهره‌وری حافظه مجازی (VM)، از مضربی از 4k استفاده کنید. برای سازگاری با HTTP/2، این مقدار باید حداقل 20k باشد تا بتوان فریم‌هایی با اندازه کامل (=16k) را از کلاینت دریافت کرد. این امر معمولاً تنها در بدنهٔ درخواست‌های POST/PUT رخ می‌دهد. برای سایر الگوهای ترافیکی (traffic-patterns)، مقادیر کوچک‌تر کاملاً مناسب خواهند بود..SS workspace_session

اندازه تخصیص برای ساختار نشست (session) و فضای کاری. فضای کاری عمدتاً برای نشانی‌های اتصال TCP به کار می‌رود. در صورتی که بزرگ‌تر از 4k باشد، برای کارایی بهتر حافظه مجازی (VM)، از مضربی از 4k استفاده کنید.

workspace_thread

میزان بایت‌های فضای کاری کمکی به ازای هر رشته (thread). این فضای کاری در طول فعالیت یک رشته کاری (worker thread)، برای برخی ساختارهای داده‌ای موقت استفاده می‌شود. یکی از کاربردهای آن برای IO-vectorهای مورد استفاده در حین تحویل است. تنظیم این پارامتر روی مقداری بیش از حد کم ممکن است تعداد فراخوانی‌های سیستمی writev() را افزایش دهد، و تنظیم بیش از حد زیاد آن تنها فضا را هدر می‌دهد. مقدار ~0.1k + UIO_MAXIOV * sizeof(struct iovec) (معمولاً = ~16k برای ۶۴ بیتی) در هر شرایط شناخته‌شده‌ای (به استثنای کاربردهای نامتعارف vmod)، حداکثر مقدار معقول در نظر گرفته می‌شود.