میزبانی وب‌سایت معمولاً با اجاره سرور مجازی (VPS) و نصب سیستم‌عامل‌هایی مانند اوبونتو یا دبیان انجام می‌شود؛ اما یک توسعه‌دهنده با بیش از نیم‌دهه تجربه در این حوزه، مسیر متفاوتی را آزموده است: میزبانی یک وب‌سایت واقعی روی برد میکروکنترلر ۵ دلاری ESP32. نتیجه این آزمایش نشان می‌دهد که این برد کوچک، بسیار فراتر از تصور اولیه، توانایی پاسخ‌گویی به درخواست‌های HTTP را دارد.
آزمایش اولیه: آیا ESP32 توان میزبانی دارد؟
نویسنده برای فلش کردن کد (Sketch) روی برد از محیط توسعه Arduino IDE استفاده کرده و علاوه بر کتابخانه‌های معمول، به دو کتابخانه ESPAsyncWebServer و AsyncTCP نیاز داشته است. یک کد، یک فایل HTML ساده و یک اسکریپت پایتون برای تست بار (Load Testing)، کل تجهیزات این آزمایش را تشکیل می‌دادند. کد در چند ثانیه روی برد اجرا شد؛ اما پرسش اصلی این بود که آیا ۵۲۰ کیلوبایت حافظه SRAM برد از پس چند کاربر همزمان برمی‌آید یا خیر.
اسکریپت تست بار به‌گونه‌ای تنظیم شده بود که به ترتیب ۱، ۵، ۱۰، ۲۵، ۵۰ و ۱۰۰ اتصال همزمان (Concurrent Connections) ایجاد کند و در هر سطح ۱۵ ثانیه توقف داشته باشد. کد فلش‌شده دو نقطه پایانی (Endpoint) کوچک با نام‌های /ping و /stats را نیز در اختیار می‌گذاشت؛ /ping تنها زمان برقراری اتصال را می‌سنجید و /stats آمار هر اتصال مانند زمان فعالیت (Uptime)، حافظه آزاد (Free Heap) و تعداد کل درخواست‌ها را ثبت می‌کرد.
نتایج تست بار روی صفحه آزمایشی
- حجم صفحه ارسالی: حدود ۲.۳ کیلوبایت (بدون فشرده‌سازی)
- اوج توان عبوری (Throughput) صفحه اصلی: حدود ۲۰۰ درخواست در ثانیه
- اوج توان عبوری نقطه پایانی /ping: حدود ۲۵۰ درخواست در ثانیه
- میانه تأخیر (Median Latency) در یک اتصال: حدود ۷.۸ میلی‌ثانیه
- نقطه اوج توان عبوری: حدود ۱۰ اتصال همزمان
- نخستین خطاها: از ۲۵ اتصال همزمان
- تعداد خطا در ۱۰۰ اتصال همزمان: ۴۵۸ خطا
- کمترین حافظه آزاد: ۱۳۷ تا ۱۴۰ کیلوبایت
- تعداد ری‌استارت (Reboot): صفر
اتصالات ۱، ۵ و ۱۰ همزمان هیچ فشاری بر برد وارد نکردند و نخستین مشکلات جدی عملکردی از سطح ۲۵ اتصال آغاز شد. نکته مهم آن بود که برد هرگز ری‌استارت نشد و حافظه آزاد نیز هرگز پایین‌تر از محدوده انتظار نرفت؛ بنابراین گلوگاه اصلی، تعداد اتصالات همزمان بود و نه پاسخ‌دهی HTTP.
انتقال نمونه‌کار واقعی؛ صفحه سنگین‌تر، سرعت کمتر
محدودیت واقعی این پروژه، نبود دیسک مانند سرور بود؛ تنها ۴ مگابایت حافظه فلش (Flash) و حدود ۳۲۰ کیلوبایت از SRAM به‌عنوان داده معمول در دسترس قرار داشت. به همین دلیل، نویسنده نمونه‌کار شخصی خود را که با Next.js ساخته شده و روی Cloudflare Pages میزبانی می‌شد، به یک پروژه ساده HTML/CSS تبدیل کرد و ابتدا تنها صفحه اصلی، سپس نسخه کامل‌تر شامل صفحه اصلی، فهرست پروژه‌ها، هفت مطالعه موردی (Case Study) و یک وبلاگ را روی برد منتقل کرد.
در این انتقال، تصاویر حذف شدند؛ زیرا تصویر شاخص و سه تصویر پروژه‌ها در صفحه اصلی مجموعاً بیش از ۵۰۰ کیلوبایت حجم داشتند. به‌جای آن‌ها از آیکون‌های SVG درون‌خطی (Inline SVG) و فونت‌های سیستمی استفاده شد و در نهایت همه صفحات پیش از ارسال، با الگوریتم gzip فشرده و از حافظه فلش سرو شدند.
- حجم صفحه ارسالی: حدود ۶.۹ کیلوبایت فشرده‌شده (حدود ۲۰ کیلوبایت خام)
- توان عبوری صفحه اصلی در ۵ تا ۱۰ اتصال: حدود ۱۲۵ تا ۱۳۰ درخواست در ثانیه
- میانه تأخیر در یک اتصال: حدود ۱۳ میلی‌ثانیه
- تعداد خطا در ۱۰۰ اتصال همزمان: حدود ۱۱۱ تا ۱۲۸ خطا
- کمترین حافظه آزاد: حدود ۸۰ تا ۸۷ کیلوبایت
- تعداد ری‌استارت: صفر
با سه‌برابر شدن حجم صفحه، توان عبوری حدود یک‌سوم کاهش یافت و میانه زمان پاسخ از ۷.۸ به ۱۳ میلی‌ثانیه رسید؛ اما جالب آنکه تعداد خطاها در ۱۰۰ اتصال همزمان از ۴۵۸ در صفحه آزمایشی به ۱۱۱ تا ۱۲۸ کاهش پیدا کرد. در مجموع حدود ۷۰ هزار درخواست با نرخ تقریبی ۱۲۵ درخواست در ثانیه روی صفحه اصلی ثبت شد.
انتشار عمومی و نقش کلیدی کش
برای دسترسی عمومی، نویسنده از آدرس IP عمومی ارائه‌دهنده خدمات اینترنت خود و نرم‌افزار Nginx Proxy Manager (NPM) روی سرور دبیان خانگی بهره گرفت. مراحل شامل رزرو DHCP روی گیت‌وی ER605، ثبت یک زیردامنه DNS-only در Cloudflare، افزودن هاست جدید در NPM همراه با گواهی Let's Encrypt و ایجاد یک ناحیه کش (Cache Zone) برای پروکسی ESP32 بود. صفحات به مدت ۵ دقیقه و نقطه پایانی /stats به مدت ۱۰ ثانیه کش می‌شدند و دسترسی به /ping نیز مسدود شد.
سپس تست بار از یک سرور مجازی در نورنبرگ آلمان اجرا شد تا مسیر واقعی اینترنت عمومی سنجیده شود. در اجرای همراه با کش، حدود ۴۵۳۰ درخواست تولید شد اما شمارنده بازدید برد تنها حدود یک دوجین جابه‌جا شد که ۷ تا ۸ مورد آن مربوط به بازخوانی صفحه توسط خود نویسنده بود. در این حالت کمترین حافظه آزاد حدود ۸۰ کیلوبایت، میانه تأخیر حدود ۱۵۸ میلی‌ثانیه و تنها یک خطا در ۲۵ اتصال و ده خطا در ۵۰ اتصال ثبت شد. در اجرای بدون کش (با استفاده از پارامتر --bust برای دور زدن کش)، ۱۸۱۰ پاسخ موفق با میانه تأخیر ۱۸۰ میلی‌ثانیه، صفر خطا در ۱۰ اتصال و ده خطا در ۲۵ اتصال به دست آمد.
نویسنده یک رفتار غیرمنتظره نیز مشاهده کرده است: سرور چند بار هنگام برقراری اتصال از سمت سرور مجازی متوقف شده؛ به‌طور دقیق حدود ۴ مورد از هر ۱۰۰ اتصال تازه، یک مورد هنگام اتصال و سه مورد پس از دست‌دادن TLS و پیش از ارسال نخستین بایت. این رفتار در هر دو حالت کش‌شده و بدون کش رخ داده و دلیل آن مشخص نشده است.
آیا ESP32 جایگزین هاست سنتی می‌شود؟
پاسخ کوتاه این است که بله، یک برد ۵ دلاری ESP32 می‌تواند یک وب‌سایت واقعی را میزبانی کند؛ اما این به معنای جایگزینی میزبانی سنتی نیست. یک نمونه‌کار ایستا بار کاری بسیار کمتری نسبت به یک اپلیکیشن فول‌استک React با پایگاه داده، بک‌اند و احراز هویت دارد. نویسنده اعلام کرده که قصد ندارد این راهکار را جایگزین سرویس‌های میزبانی رایگانی مانند Cloudflare Pages و GitHub Pages کند و هدف او تنها سنجش این بوده است که سخت‌افزار ارزان‌قیمت، در صورت انتخاب دقیق بار کاری، تا چه اندازه می‌تواند پیش برود. او قرار است برد را برای چند هفته به‌صورت پیوسته روشن نگه دارد تا آزمون پایداری بلندمدت (Soak Test) انجام دهد.