কখন একটি শেয়ার্ড প্রক্সি ক্যাশ ক্রলারকে সাহায্য করে

ধরা যাক, ব্রাউজারে চলা কয়েকজন ওয়ার্কার একটি সাইটের আলাদা আলাদা পৃষ্ঠা খোলে। সেই পৃষ্ঠাগুলো একই স্টাইলশিট, লোগো ও স্ক্রিপ্ট বান্ডল উল্লেখ করে। শেয়ার্ড ফরওয়ার্ড ক্যাশ প্রথম ফেচটিকে পরবর্তী ওয়ার্কারদের জন্য কাজে লাগাতে পারে, যখন প্রতিক্রিয়াগুলো পুনরায় ব্যবহারযোগ্য হয়।

এখন কাজের ধরন বদলান: প্রতিটি ওয়ার্কার কেবল একটি HTML নথি নামায় এবং তার সংযুক্ত সম্পদ কখনো লোড করে না। সাধারণ স্টাইলশিটটি মার্কআপে এখনো আছে, কিন্তু কোনো ওয়ার্কার তা অনুরোধ করে না। এটি প্রক্সির ক্যাশ হিট হার-এ কিছুই যোগ করে না।

আপনার ক্রলার আসলে যে অনুরোধ করে, তা দিয়ে শুরু করুন

পৃষ্ঠা রেন্ডার করা ব্রাউজার এবং তার সোর্স আনা HTTP ক্লায়েন্ট ভিন্ন ভিন্ন অনুরোধ-সমষ্টি তৈরি করে। ক্যাশ ডিজাইন বাছার আগে সেই সমষ্টিগুলো পরীক্ষা করুন।

কেবল URL সমতা যথেষ্ট নয়। প্রতিক্রিয়ার সতেজতা নীতি এবং Vary-তে উল্লিখিত ফিল্ড উপস্থাপনাগুলো আলাদা করতে পারে। ব্যক্তিগত, সংরক্ষণ-অযোগ্য বা প্রমাণিত বিষয়বস্তুর জন্য প্রযোজ্য শেয়ার্ড-ক্যাশ নিয়ম দরকার; কেবল হিট সংখ্যা বাড়াতে এটি একটিমাত্র পাবলিক ফলাফলে জোর করে ঢোকানো উচিত নয়।

সাধারণ HTTPS CONNECT ট্র্যাফিকে ফরওয়ার্ড প্রক্সি একটি এনক্রিপ্ট করা টানেল বহন করে এবং এর ভিতরে ক্যাশ করার মতো কোনো HTTP বস্তু থাকে না। TLS-পরিদর্শন স্থাপনার বিশ্বাস ও প্রক্রিয়াকরণ আচরণ ভিন্ন। বস্তু-ক্যাশিং পাওয়া যাবে কি না যাচাই করার সময় প্রকৃত মোডটি অন্তর্ভুক্ত করুন।

ক্যাশ হিট আপস্ট্রিম ফেচ এড়াতে পারে, আর মিস হলে মধ্যস্থের কাজের খরচ তবু দিতে হয়। লক্ষ্য কাজের জন্য সম্পূর্ণ উপযোগী বাইট, আপস্ট্রিম ট্র্যাফিক ও লেটেন্সি তুলনা করুন। থ্রেড সংখ্যা সমকালীনতা বোঝায়; সেই থ্রেডগুলো কত পুনর্ব্যবহারযোগ্য বিষয়বস্তু ভাগ করে, তা বোঝায় না।