چرا یک برنامه SQL پرحرف از طریق VPN کند می‌شود و چه چیزی را دسته‌ای کنیم
صفحه‌ای که صد پرس‌وجوی وابسته می‌فرستد، هزینه رفت‌وبرگشت را صد بار می‌پردازد. انتظارها را بشمارید، مستقل‌ها را دسته کنید و سپس اجرا را جابه‌جا کنید.
فرمی که در شبکه محلی در کمتر از یک ثانیه نمایش داده می‌شود، از طریق VPN پنج ثانیه طول می‌کشد، در حالی که کپی یک فایل روی همان خط با تمام سرعت اجرا می‌شود. تفاوت در پهنای باند نیست. فرم منتظر زنجیره‌ای از پاسخ‌ها می‌ماند و در هر گام هزینه کامل رفت‌وبرگشت را می‌پردازد، در حالی که کپی فایل بایت‌ها را پیوسته در مسیر نگه می‌دارد. پیش از دست زدن به خط دسترسی، این انتظارها را بشمارید.
نشانه یک صفحه است، نه یک پرس‌وجو
هر پرس‌وجو روی آن صفحه می‌تواند سریع باشد و صفحه همچنان کند بماند، زیرا مجموع، جمع انتظارهاست نه جمع زمان‌های اجرا. دستوری که در دو میلی‌ثانیه اجرا می‌شود، باز هم یک رفت‌وبرگشت کامل هزینه دارد وقتی مشتری باید نتیجه‌اش را پیش از فرستادن دستور بعدی دریافت کند. در مسیری با تأخیر چهل میلی‌ثانیه، صد فراخوانی وابسته پیش از آغاز هر کار رسم، حدود چهار ثانیه جمع می‌شوند. این حساب، مدلی از انتظار است، نه سنجشی از خط شما.
به همین دلیل آزمون سرعت بی‌گناه به نظر می‌رسد. انتقال انبوه توان عبوری را می‌سنجد، فرم پرحرف تأخیر را می‌سنجد، و VPN می‌تواند در یکی عالی و در دیگری معمولی باشد. پس تشخیص صفحه یعنی سنجیدن صفحه، نه خط.
پیش از تغییر هر چیز، زمان سرتاسری یک کنش کاربر را ثبت کنید. آن عدد تنها خط پایه‌ای است که می‌تواند بگوید اصلاح بعدی کار کرده یا نه.
انتظارهای پیاپی را در یک کنش کاربر بشمارید
در مشتری اندازه بگیرید، نه با حدس. در psql دستور \timing on زمان سپری‌شده هر دستور را چاپ می‌کند و EXPLAIN (ANALYZE, BUFFERS) نشان می‌دهد سرور واقعاً چه بخشی از آن زمان را صرف کار کرده است.
فاصله میان این دو عدد، سرباز شبکه و مشتری شماست. اگر دستوری در دو میلی‌ثانیه اجرا شود و مشتری شصت ثبت کند، پنجاه و هشت باقی‌مانده سفر و پردازش محلی است و هیچ نمایه‌ای آن‌ها را حذف نمی‌کند. این مقایسه را برای هر دستوری که صفحه صادر می‌کند تکرار کنید و فاصله‌ها را جمع بزنید، نه زمان‌های اجرا را.
نتیجه را به شکل شمار انتظارهای پیاپی بنویسید. این همان کمیتی است که دو بخش بعدی می‌توانند کاهش دهند، و عددی است که می‌توانید با شواهد درباره‌اش بحث کنید.
فراخوانی‌های مستقل را دسته کنید، وابسته‌ها را نگه دارید
دو دستور که نتایج یکدیگر را نمی‌خوانند می‌توانند با هم سفر کنند و یک بار جمع‌آوری شوند، که دو انتظار را به یکی تبدیل می‌کند. دو دستوری که دومی به مقدار اولی نیاز دارد نمی‌توانند، زیرا وابستگی واقعی است و دسته کردن آن رفتار برنامه را تغییر می‌دهد. پیش از بازنویسی هر چیز، فراخوانی‌ها را در این دو توده دسته‌بندی کنید، و اندازه هر توده به شما می‌گوید چه چیزی ممکن است.
کار مبتنی بر مجموعه‌ها انتظارها را عمیق‌تر از دسته‌بندی برمی‌دارد. یک پرس‌وجو که ردیف‌هایی را برمی‌گرداند که حلقه یکی‌یکی می‌آورد، هم حلقه را حذف می‌کند و هم رفت‌وبرگشت‌ها را. نخست حلقه را بجویید، زیرا معمولاً سود بزرگ‌تر و تغییر آسان‌تر برای بازبینی است.
دسته باید همچنان مدیریت خطا و مرزهای تراکنش را حفظ کند. به هم چسباندن دستورهای بی‌ارتباط در یک رشته، بهینه‌سازی ایمنی نیست، و دسته‌ای که دستور ناموفق را پشت ارسال موفق پنهان می‌کند، از انتظارهایی که صرفه‌جویی کرده بدتر است.
پیش از خریدن پهنای باند، اتصال‌ها را دوباره به کار ببرید
اتصال تازه هزینه تجزیه نام، دست‌دادن TCP، مذاکره TLS و احراز هویت را دارد، و در مسیری با تأخیر بالا هر یک از این‌ها رفت‌وبرگشتی دیگر است پیش از آنکه نخستین پرس‌وجو اجرا شود. استخرهای اتصال برای پرداخت یک‌باره این هزینه در هر فرایند وجود دارند، نه یک‌بار در هر فراخوانی.
در ADO.NET، بستن یا رها کردن یک اتصال استخری آن را برای استفاده دوباره برمی‌گرداند، نه اینکه اتصال فیزیکی تازه‌ای باز کند، پس الگویی که شبیه نشت به نظر می‌رسد اغلب استفاده درست است. به‌جای فرض کردن، بررسی کنید که استخر واقعاً به کار می‌رود: ایجاد اتصال‌های فیزیکی را ثبت کنید یا هنگام اجرای صفحه، شمار نشست‌ها روی سرور را بپایید. راهنمای کارایی SQL همین نکته را درباره کاهش رفت‌وبرگشت‌ها و دسته کردن فراخوانی‌های موردی مکرر می‌گوید، با نمونه‌های ویژه هر سرویس که باید آن‌ها را به استقرار خودتان نگاشت کنید.
استخر کردن، هزینه راه‌اندازی را برمی‌دارد و انتظارهای پیاپی پرس‌وجو را دست‌نخورده می‌گذارد. این پیش‌نیاز سنجش پاک است، نه اصلاحی به‌تنهایی.
جابه‌جا کردن اجرا به داده‌ها را بسنجید
اجرای برنامه نزدیک پایگاه داده، بسیاری از تبادل‌های دور با پایگاه داده را با یک نشست نمایش دور جایگزین می‌کند. برای باری پرحرف این می‌تواند تغییری بزرگ باشد، و همان‌قدر که تغییری در کارایی است، تغییری عملیاتی نیز هست: مدیریت نشست، کنترل دسترسی، استقرار نرم‌افزار و تجربه کاربر همه با برنامه جابه‌جا می‌شوند.
پیش از فرض کردن اینکه هر جهت سریع‌تر است، رابط واقعی و داده‌ای را که منتقل می‌کند بسنجید. نشست دسکتاپ دور پیکسل‌ها را جابه‌جا می‌کند، و صفحه‌ای با گرافیک انبوه می‌تواند روی همان مسیر بدتر از پرس‌وجوهایی که جایگزینشان شده عمل کند، به‌ویژه وقتی مشتری پیوسته دوباره رسم می‌کند.
سپس کنش اصلی را تکرار کنید و سه عدد را بسنجید: انتظارهای پیاپی، حجم نتیجه و زمان تکمیل سرتاسری. بهبودی که وظیفه سنجیده‌شده کاربر را تغییر می‌دهد و در همان حال درستی داده و سیاست دسترسی را حفظ می‌کند، همانی است که ارزش نگه داشتن دارد.