Varnish cache یک شتاب دهنده http و پروکسی معکوس است که توسط Danish مشاور و توسعه دهنده اصلی Freebsd به همراه توسعه دهنده های دیگر در Norwegian Linpro AS ایجاد و در سال 2006 منتشر شد. طبق گفته سایت pingdom.com، سایتی که روی کارایی وب تمرکز دارد، در سال 2012 وارنیش (Varnish) به عنوان افزایش دهنده سرعت وب در بین تمام توسعه دهندگان و وب سایت ها معروف بود و هم اکنون در سایت هایی مانند Wired, SlideShare, Zappos, SoundCloud, Weather.com, Business Insider, Answers.com, Urban Dictionary, MacRumors, DynDNS, OpenDNS, Lonely Planet, Technorati, ThinkGeek and Economist.com از آن استفاده می کنند.
Varnish تحت مجوز BSD لایسنس شده است. varnish یک لایه تجاری به نام varnish plus هم دارد که روی مشتریان سازمانی تمرکز کرده است و ویژگی های منحصر به فرد و ماژول ها و پشتیبانی به موقع را ارائه می دهد.
اگر چه راه حل های دیگری مانند shine هم وجود دارد اما varnish یک راه حل بهتری است که می تواند باعث بهبود چشمگیر سرعت وب سایت، کاهش بار اضافی برنامه ها روی پردازنده های سرور شود و حتی یک برنامه برای حفاظت از حملات DDOS هم ارائه می دهد.
سایت keyCDN پیشنهاد می کند که آنرا روی سرور اصلی قرار دهید. در سایت های پر بازدید می توانید varnish را روی یک سرور اختصاصی پیکربندی کنید و بدین ترتیب مطمئن می شوید که سرور اصلی از درخواست های زیاد کاربران تاثیر نمی گیرد.
وارنیش کش چگونه به وجود آمد؟
وارنیش در ابتدا یک ایده بود که توسط یک روزنامه نروژی استفاده شد و پس از آن Paul Hening Kamp که عموماً به عنوان یک دولوپر هسته FreeBSD شناخته میشود ، شروع به توسعه وارنیش کرد. ساختار امروزی وارنیش بسیار متفاوت از زمانی است که در ابتدا معرفی شد و وی ساختار سرویسدهی و همچنین نوع سرویسدهی را بر روی وارنیش تغییر داد.
این سرویس کشینگ در ابتدا در سال 2006 با نسخه 1 معرفی شد و بعدها با نسخه های 2 و 3 و در نهایت در سال 2016 با نسخه پنج در دسترس قرار گرفت.
نکته جالب توجه نسبت به این ابزار این است که وارنیش از ابتدا تا اکنون زیر نظر BSD License فعالیت داشته و به صورت رایگان در اختیار تمام کاربران قرار دارد و شما نیز میتوانید با نصب آن بر روی سرور خود ، براحتی از وارنیش استفاده کنید.
در حال حاضر وبسایتهای بزرگی از این سیستم استفاده کرده که در بین آنها میتوان به ویکیپدیا و بسیاری از روزنامههای آنلاین مانند The New York Times ، The Guardian ، Corriere della sera و همچنین بسیاری از شبکههای معروف اجتماعی مانند Facebook ، Twitter ، Reddit ، Vimeo و ... نام برد، به طور کلی وارنیش کش برای وبسرورهایی طراحی شده است که ترافیک بسیار بالایی داشته و به طور مداوم در حال سرویسدهی هستند. از دیگر مزایای مهمی که استفاده از وارنیش برای وب سرور شما به ارمغان خواهد آورد ، افزایش امنیت وب سرور شما خواهد بود و این امنیت ناشی از قرار گرفتن وب سرور آپاچی و یا Nginx پشت وارنیش است و ارتباط مستقیمی با بیرون نخواهد داشت.
استفاده از varnish کش برای چه سایتهایی توصیه نمیشود؟
آن دسته از وب سایتهایی که به صورت مرتب اطلاعات آنها در حال آپدیت هستند مانند سایتهای خبری، اینگونه سایت ها با استفاده از هرگونه کشی مشکل خواهند داشت زیرا مطالب آنها به صورت مرتب و حتی دهها بار در روز آپدیت میشوند و همین امر باعث میشود کاربرانی که وبسایت را به صورت مرتب و دورهای بررسی میکنند با مشکل رو به رو شده و همان مطالب قدیمی برای آنها نمایش داده شود به دلیل اینکه اطلاعات به صورت ذخیره شده بر روی مرورگر کاربر قرارگرفته و هر سری همان مطالب به صورت دورهای برای آنها نمایش داده میشود مگر اینکه کانفیگ varnish به درستی و بسته به نیاز وبسایت زمانبندی شود تا رفرش کش قبل از پست جدید ارسالی انجام شود که خود این مورد به دلیل آپدیتهای متوالی عملاً کاربرد کش را خنثی خواهد کرد.
وارنیش (Varnish) چگونه کار می کند؟
وارنیش به طور کلی پس از نصب همانند یک Proxy Server شروع به فعالیت کرده و جلوی وب سرور آپاچی یا Nginx قرار میگیرد و تمامی درخواستها به سمت سرور ، در ابتدا توسط وارنیش آنالیز شده و پاسخ مناسب به کاربر ارسال خواهد شد.
به طور کلی اگر از درخواست کاربر قبلاً در وارنیش کش شده باشد ، بدون برقراری ارتباط با وب سرور ، خود وارنیش پاسخ کاربر را ارسال خواهد کرد و در صورتی که درخواست کاربر در وارنیش وجود نداشته باشد ، وارنیش از وب سرور اطلاعات را دریافت کرده و پس از نسخهبرداری در حافظه کش ، آن را برای کاربر ارسال میکند. این نوع عملکرد ، در سرور باعث کاهش مصرف رم و پردازنده شده و همچنین با سرعت بسیار بالاتری به درخواستها پاسخدهی خواهد شد.
در یک وب سرور معمولی تمامی درخواستها به سمت آپاچی رفته و آپاچی تک تک درخواستها را اجرا کرده و با سرویس پایگاه داده و PHP مداوماً در ارتباط خواهد بود. اما در وب سروری که وارنیش روی آن اجرا شده است درخواستها به سمت وارنیش آمده و این سرویس کشینگ در ابتدا به حافظه خود مراجعه خواهد کرد تا بتواند پاسخ کاربر را بدهد ، در صورتی که درخواست کاربر با پاسخهای موجود در حافظه مطابقت نداشته باشد ، از وب سرور آپاچی پاسخ ارسال خواهد شد.
به همین ترتیب ، سرعت سرویسدهی افزایش یافته و آپاچی نیازی به اجرای کدهای یک وب سایت و خواندن محتوا از MySQL نخواهد داشت و بر همین اساس ، عملکرد آپاچی ، MySQL و PHP کاهش پیدا کرده و مقدار مصرف رم و پردازنده سرور بسیار کاهش پیدا خواهد کرد.
سایت رسمی Varnish، چنین تعریفی از آن ارائه می دهد: “ورنیش یک شتاب دهنده حرفه ای وب سرور است که با نام HTTP Reverse Proxy هم شناخته می شود.”
اگر به کارهایی که وب سرور در مواقع غیرطبیعی انجام می دهد دقت کنید، می بینید که درخواست های HTTP را گرفته و پاسخ هایی از نوع HTTP به آنها می دهد. در حالت ایده آل، وقتی وب سرور درخواستی را می گیرد بدون اینکه کار زمان بری انجام دهد، بلافاصله به آن پاسخ می دهد. اما در واقعیت، در اغلب موارد، وب سرور باید زمان قابل توجهی را صرف انجام درخواست کند و سپس پاسخ را برای مشتری ارسال کند. در این مقاله، قصد داریم نحوه پاسخگویی یک وب سرور معمولی به درخواست ها را برای شما شرح دهیم و پس از آن به شما نشان دهیم Varnish چطور این وضعیت را بهبود می بخشد. ابزار اصلی تنظیمات وارنیش، زبان پیکربندی Varnish یا VCL است که یک زبان خاص دومین (Domain-Specific Language) DSL است که برای ساختن روال هایی که در زمان پاسخ اولیه به هر درخواست فراخوانی می شوند، استفاده می گردد. بیشتر تنظیمات، در کد VCL انجام می شود و به همین علت varnish را نسبت به اغلب عوامل دیگر تسریع کننده HTTP، قابل تنظیم تر و تطبیق پذیرتر می کند.
اگر چه هر سرور شرایط مخصوص به خود را دارد، اما یک وب سرور معمولی، مجموعه ای طولانی از اقدامات را برای پاسخ به هر درخواستی که دریافت می کند، انجام می دهد. این روند معمولا با ایجاد روال دیگری برای مدیریت درخواست ها آغاز شود. در این مرحله، شاید نیاز باشد رکورد های اسکریپت از چرخه بارگذاری شده، یک روال واسط برای رمزگشایی فراخوانی شده و آن اسناد را به bytecode تبدیل کند.
سپس، وب سرور این bytecode را اجرا می کند، ممکن است اجرای این کد بار کاری بیشتری به همراه آورد. مثل اجرای کوئری های سنگین SQL و بازیابی رکورد های بیشتر از چرخه کار. حال تصور کنید این روند با صدها یا هزاران تقاضا، تکرار شود، الان بهتر می توانید درک کنید که یک سرور چطور به یکباره دچار بار بیش از حد می شود و فریم ورک آن تلاش می کند تا به همه درخواست ها پاسخ دهد.
بدتر از همه اینکه تعداد زیادی از درخواست ها در واقع تکرار همان درخواست های اولیه هستند، اما ممکن است سرور راهکاری برای فراخوانی مجدد پاسخ قبلی خود به این درخواست نداشته باشد. بنابراین، سرور باید همان فرآیند مشابه و پر زحمت قبل را بارها و بارها از قدم اول برای پاسخگویی به هر درخواست تکرار کند.
پارامترهایی که تاکنون در موردشان صحبت کردیم، همه توسط وارنیش قابل تنظیم هستند. مثلا می توانیم انتخاب کنیم که یک درخواست توسط وارنیش بازیابی گردد، نه توسط وب سرور. سپس وارنیش نگاهی به آنچه مورد درخواست قرار گرفته می اندازد و درخواست را به سمت وب سرور می فرستد (که به عنوان یک سرور Backend برای وارنیش شناخته می شود). سرور Backend کار معمول و همیشگی خود را انجام می دهد و نتیجه را به وارنیش بر می گرداند، و در نهایت وارنیش هم نتیجه را به کاربر اولیه ای که آن را درخواست کرده است تحویل می دهد.
به احتمال زیاد این همه کاری که از دست Varnish برمی آید نیست، چون تا اینجا که کمک زیادی به روند کار نکرد. چیزی که Varnish به این روند اضافه می کند این است که، Varnish قادر است پاسخ های سرور backend را ذخیره و برای استفاده در آینده رزرو کند. وارنیش سریعا می تواند از ذخیره های خود استفاده کرده و به درخواست های بعدی پاسخ دهد، بدون اینکه بار غیر ضروری به وب سرور تحمیل کند.
اگر کمی به این کمک بزرگ Varnish فکر کنیم به این نتیجه می رسیم که باعث کاهش انباشته شدن درخواست ها می شود، زمان پاسخ را بهبود می بخشد و نهایتا درخواست های بیشتری در هر ثانیه توسط سرور پاسخ داده می شوند.
چیزی که باعث سرعت فوق العاده Varnish شده این است که پاسخ های رزرو خود را درون صفحه نگهداری نمی کند بلکه آنها را در حافظه نگه می دارد. این مورد به همراه پیشرفت های دیگر به Varnish اجازه می دهد تا تقاضا ها را با سرعت چشمگیری پردازش کند. با این اوصاف، چون معمولا حافظه از صفحه محدودتر است، باید میزان فضای مورد نیاز برای وارنیش خود را تخمین بزنید و اقداماتی انجام دهید تا درخواست هایی که باعث تلف شدن این فضای مفید می شوند در آن ذخیره نشوند.
Varnish جهت تنظیم بار هم از الگوریتم Round Robin و هم الگوریتمی اختیاری استفاده می کند. از هر دو برای تقسیم بار مناسب برای هر سرور backend استفاده می کند. علاوه براین، امکان بررسی سالم بودن سرور های backend هم وجود دارد.
ویژگی های Varnish
Varnish اصطلاحا Theaded است و مطابق گزارش ها قادر می باشد که بیش از ۲۰۰۰۰۰ درخواست در ثانیه را تنها روی یک نمونه (instance) مدیریت کند. اگر varnish به درستی پیکربندی شود تنها محدودیت برنامه وب شما توان شبکه و میزان رم خواهد بود.
Varnish با VMODS گسترش پیدا می کند. این ها ماژول هایی هستند که از کتابخانه استاندارد استفاده کرده و عملکرد varnish را افزایش می دهند.
Varnish یک زبان domain-specific مختص به خود به نام VCL دارد. VCL یک روش جامع برای پیکربندی ارائه می دهد.
هنگامی که ما یک وب سایت دینامیک با صدها یا هزاران صفحه به همراه مسیرهای مختلف را با پارامترهای کوئری Get کش می کنیم، می خواهیم بعضی از آنها را از داخل کش خارج یا نقش های cache-expiration متفاوتی را برای آن تنظیم کنیم.
بعضی مواقع می خواهیم که درخواست های Ajax را کش کنیم، یا آنها را از کش خارج کنیم. این کار از یک پروژه تا پروژه دیگر فرق می کند و نمی توان یک روش از قبل طراحی شده برای آن ارائه داد. بعضی مواقع ما می خواهیم که Varnish تصمیم بگیرد که بسته به هدر درخواست، چه کاری را انجام دهد.
امیدوارم مقاله
varnish چیست که برای شما ارائه کردیم مفید واقع شده باشد.
برای صحبت پایانی هم
آسان رایان یک تذکر برایتان دارد: اینکه اگر با نحوه کانفیگ سرور آشنایی ندارید به هیچ عنوان این کش را بر روی سرور خودتان راهاندازی نکنید تا با مشکلات مربوط با آن روبرو نشوید.