RTB অ্যাপ্লিকেশনের জন্য সর্বোত্তম অনুশীলন

এই নির্দেশিকাটি RTB প্রোটোকল অনুযায়ী অ্যাপ্লিকেশন বিকাশ করার সময় বিবেচনা করার জন্য সর্বোত্তম অনুশীলনগুলি ব্যাখ্যা করে।

সংযোগগুলি পরিচালনা করুন

সংযোগগুলি জীবিত রাখুন

একটি নতুন সংযোগ স্থাপন করা বিলম্ব বাড়ায় এবং বিদ্যমান সংযোগটি পুনরায় ব্যবহার করার চেয়ে উভয় প্রান্তে অনেক বেশি সংস্থান নেয়। কম সংযোগ বন্ধ করে, আপনি সংযোগের সংখ্যা কমাতে পারেন যা আবার খুলতে হবে।

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

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

বন্ধ সংযোগ এড়িয়ে চলুন

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

• নিষ্ক্রিয় সময়সীমা 2.5 মিনিটে।
• সর্বোচ্চ সম্ভাব্য মানের একটি সংযোগে অনুরোধের সর্বাধিক সংখ্যা।
• আপনার RAM যে সর্বোচ্চ মানের সাথে সংযোগ স্থাপন করতে পারে তার সর্বোচ্চ সংখ্যা, সংযোগের সংখ্যাটি সেই মানটির কাছাকাছি না যায় কিনা তা যাচাই করার যত্ন নেওয়ার সময়।

Apache-এ, উদাহরণস্বরূপ, এর জন্য KeepAliveTimeout 150-এ সেট করা, MaxKeepAliveRequests শূন্য করা এবং MaxClients এর মান সার্ভারের প্রকারের উপর নির্ভর করে।

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

সংযোগগুলি ভারসাম্য বজায় রাখুন

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

যখন কিছু সংযোগ ব্যাপকভাবে ব্যবহার করা হয়, তখন অন্যান্য খোলা সংযোগগুলি বেশিরভাগ নিষ্ক্রিয় থাকতে পারে কারণ সেগুলি সেই সময়ে প্রয়োজন হয় না। অনুমোদিত ক্রেতাদের ট্রাফিক পরিবর্তনের সাথে সাথে নিষ্ক্রিয় সংযোগগুলি সক্রিয় হয়ে উঠতে পারে এবং সক্রিয় সংযোগগুলি নিষ্ক্রিয় হতে পারে৷ সংযোগগুলি খারাপভাবে ক্লাস্টার করা থাকলে এগুলি আপনার বিডার সার্ভারগুলিতে অসম লোড হতে পারে৷ Google 10,000 অনুরোধের পরে সমস্ত সংযোগ বন্ধ করে সময়ের সাথে সাথে স্বয়ংক্রিয়ভাবে হট সংযোগগুলিকে পুনরায় ভারসাম্য বজায় রাখার জন্য এটি প্রতিরোধ করার চেষ্টা করে। আপনি যদি এখনও আপনার পরিবেশে ট্র্যাফিক ভারসাম্যহীন হয়ে উঠতে দেখেন, তাহলে আপনি আরও কিছু পদক্ষেপ নিতে পারেন:

1. আপনি যদি ফ্রন্টএন্ড প্রক্সি ব্যবহার করেন তবে সংযোগ প্রতি একবারের পরিবর্তে অনুরোধ প্রতি ব্যাকএন্ড নির্বাচন করুন।
2. আপনি যদি হার্ডওয়্যার লোড ব্যালেন্সার বা ফায়ারওয়ালের মাধ্যমে সংযোগ প্রক্সি করে থাকেন এবং সংযোগ স্থাপন হয়ে গেলে ম্যাপিং ঠিক করা হয় তাহলে প্রতি সংযোগের জন্য সর্বাধিক সংখ্যক অনুরোধ উল্লেখ করুন। মনে রাখবেন যে Google ইতিমধ্যেই প্রতি সংযোগ প্রতি 10,000 অনুরোধের একটি উচ্চ সীমা নির্দিষ্ট করে, তাই আপনি যদি এখনও আপনার পরিবেশে হট সংযোগগুলিকে গুচ্ছবদ্ধ হতে দেখেন তবে আপনাকে কেবলমাত্র একটি কঠোর মান প্রদান করতে হবে। Apache এ, উদাহরণস্বরূপ, MaxKeepAliveRequests 5,000 এ সেট করুন
3. তাদের অনুরোধের হার নিরীক্ষণ করতে দরদাতার সার্ভারগুলিকে কনফিগার করুন এবং যদি তারা তাদের সমবয়সীদের তুলনায় ধারাবাহিকভাবে অনেক বেশি অনুরোধ পরিচালনা করে তবে তাদের নিজস্ব সংযোগগুলি বন্ধ করে দিন।

ওভারলোড সুন্দরভাবে পরিচালনা করুন

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

অঞ্চলগুলির মধ্যে (বিশেষ করে এশিয়া এবং মার্কিন পশ্চিম এবং মার্কিন পূর্ব এবং মার্কিন পশ্চিমের মধ্যে) অস্থায়ী ট্রাফিক স্থানান্তর (এক সপ্তাহ পর্যন্ত) মিটমাট করার জন্য, আমরা প্রতি ট্রেডিং অবস্থানে 7-দিনের শীর্ষ এবং QPS-এর মধ্যে 15% কুশনের সুপারিশ করি।

ভারী বোঝার অধীনে আচরণের ক্ষেত্রে, দরদাতারা তিনটি বিস্তৃত বিভাগে পড়ে:

"সবকিছুর জবাব" দরদাতা

কার্যকর করার জন্য সহজবোধ্য হলেও, ওভারলোড হলে এই দরদাতার ভাড়া সবচেয়ে খারাপ হয়। এটি সহজভাবে প্রতিটি বিডের অনুরোধে সাড়া দেওয়ার চেষ্টা করে, যাই হোক না কেন, অবিলম্বে পরিবেশন করা যাবে না এমন কোনও সারিবদ্ধ করে। যে দৃশ্যটি ঘটে তা প্রায়শই এরকম কিছু হয়:

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

এই দরদাতার বিলম্বের গ্রাফটি খুব খাড়া করাত-দাঁতের প্যাটার্নের মতো। বিকল্পভাবে, সারিবদ্ধ অনুরোধগুলি সার্ভারকে পেজিং মেমরি শুরু করে বা অন্য কিছু করে যা দীর্ঘমেয়াদী ধীরগতির কারণ হয়, এবং পিক টাইম শেষ না হওয়া পর্যন্ত বিলম্বগুলি মোটেও পুনরুদ্ধার হয় না, যার ফলে পুরো পিক সময়কালে হতাশাজনক কলআউট হার হয়। উভয় ক্ষেত্রেই, কম কলআউট তৈরি করা হয় বা সাড়া দেওয়া হয় যদি কোটা কেবলমাত্র একটি কম মান সেট করা হয়।

"ওভারলোডে ত্রুটি" বিডার

এই দরদাতা একটি নির্দিষ্ট হার পর্যন্ত কলআউট গ্রহণ করে, তারপর কিছু কলআউটের জন্য ত্রুটি ফেরত দেওয়া শুরু করে। এটি অভ্যন্তরীণ টাইমআউটের মাধ্যমে করা যেতে পারে, সংযোগ সারি অক্ষম করা (Apache-এ ListenBackLog দ্বারা নিয়ন্ত্রিত), একটি সম্ভাব্য ড্রপ মোড প্রয়োগ করা যখন ব্যবহার বা বিলম্বগুলি খুব বেশি হয়ে যায়, বা অন্য কোনও প্রক্রিয়া। যদি Google 15% এর উপরে একটি ত্রুটির হার পর্যবেক্ষণ করে, আমরা থ্রটলিং শুরু করব। "সবকিছুর প্রতি সাড়া দিন" দরদাতার বিপরীতে, এই দরদাতা "তার লোকসান কমিয়ে দেয়", যা অনুরোধের হার কমে গেলে অবিলম্বে পুনরুদ্ধার করতে দেয়।

এই দরদাতার বিলম্বের গ্রাফটি ওভারলোডের সময় একটি অগভীর করাত-দাঁতের প্যাটার্নের অনুরূপ, সর্বাধিক গ্রহণযোগ্য হারের চারপাশে স্থানীয়করণ করা হয়েছে।

"ওভারলোডের উপর নো-বিড" দরদাতা

এই দরদাতা একটি নির্দিষ্ট হার পর্যন্ত কলআউট গ্রহণ করে, তারপর কোনো ওভারলোডের জন্য "নো-বিড" প্রতিক্রিয়াগুলি ফেরত দেওয়া শুরু করে৷ "ওভারলোডে ত্রুটি" দরদাতার অনুরূপ, এটি বিভিন্ন উপায়ে প্রয়োগ করা যেতে পারে। এখানে যেটা আলাদা তা হল Google-এ কোন সিগন্যাল ফেরত দেওয়া হয় না, তাই আমরা কখনই কলআউটে পিছিয়ে যাই না। ওভারলোড ফ্রন্ট-এন্ড মেশিন দ্বারা শোষিত হয়, যা শুধুমাত্র ট্র্যাফিককে অনুমতি দেয় যা তারা ব্যাকএন্ডে চালিয়ে যেতে পারে।

এই দরদাতার জন্য বিলম্বের গ্রাফটি এমন একটি মালভূমি দেখায় যা (কৃত্রিমভাবে) সর্বোচ্চ সময়ে অনুরোধের হারের সমান্তরাল হওয়া বন্ধ করে এবং একটি বিড ধারণ করে এমন প্রতিক্রিয়াগুলির ভগ্নাংশে একটি অনুরূপ ড্রপ।

আমরা নিম্নলিখিত উপায়ে "ওভারলোডের উপর নো-বিড" পদ্ধতির সাথে "ওভারলোডে ত্রুটি"কে একত্রিত করার পরামর্শ দিই:

• ফ্রন্ট-এন্ডগুলিকে ওভার-প্রভিশন করুন এবং ওভারলোডের ক্ষেত্রে সেগুলিকে ত্রুটিতে সেট করুন, যাতে তারা কোনও আকারে প্রতিক্রিয়া জানাতে পারে এমন সংযোগের সংখ্যা সর্বাধিক করতে সহায়তা করে৷
• ওভারলোডে ত্রুটি হলে, ফ্রন্ট-এন্ড মেশিনগুলি একটি ক্যানড "নো-বিড" প্রতিক্রিয়া ব্যবহার করতে পারে এবং অনুরোধটিকে মোটেও পার্স করার দরকার নেই৷
• ব্যাকএন্ডগুলির স্বাস্থ্য-পরীক্ষা প্রয়োগ করুন, যেমন কারও কাছে পর্যাপ্ত ক্ষমতা না থাকলে, তারা একটি "নো-বিড" প্রতিক্রিয়া ফিরিয়ে দেয়।

এটি কিছু ওভারলোড শোষিত হতে দেয় এবং ব্যাকএন্ডগুলিকে ঠিক ততগুলি অনুরোধের প্রতিক্রিয়া জানানোর সুযোগ দেয় যতগুলি তারা পরিচালনা করতে পারে। আপনি এটিকে "ওভারলোডের উপর নো-বিড" হিসাবে ভাবতে পারেন যখন অনুরোধের সংখ্যা প্রত্যাশার চেয়ে উল্লেখযোগ্যভাবে বেশি হয় তখন ফ্রন্ট-এন্ড মেশিনগুলি "ওভারলোডে ত্রুটি"-এ ফিরে আসে।

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

পিংসে সাড়া দিন

আপনার দরদাতা পিং অনুরোধে সাড়া দিতে পারে তা নিশ্চিত করা, যদিও প্রতি নিজের সংযোগ ব্যবস্থাপনা নয়, ডিবাগিংয়ের জন্য আশ্চর্যজনকভাবে গুরুত্বপূর্ণ। Google বিডার স্ট্যাটাস, সংযোগ ঘনিষ্ঠ আচরণ, লেটেন্সি এবং আরও অনেক কিছুর বিচক্ষণতা-পরীক্ষা এবং ডিবাগিংয়ের জন্য পিং অনুরোধগুলি ব্যবহার করে। পিং অনুরোধগুলি নিম্নলিখিত ফর্ম গ্রহণ করে:

গুগল

id: "\3503cg\3023P\364\230\240\270\020\255\002\231\314\010\362\347\351\246\357("
is_test: true
is_ping: true

OpenRTB JSON

"id": "4YB27BCXimH5g7wB39nd3t"

OpenRTB Protobuf

id: "7xd2P2M7K32d7F7Y50p631"

মনে রাখবেন OpenRTB ping অনুরোধে is_ping সংকেত অন্তর্ভুক্ত করা হয় না। এটি কারণ OpenRTB মডেলের কোনো পিং ক্ষেত্র নেই, তাই একটি অ্যাড-হক পিং অনুরোধ পাঠানো হয়েছে, এটি একটি BidRequest যাতে শুধুমাত্র আইডি থাকে। এর জন্য দরদাতাদের কোনো বিশেষ হ্যান্ডলিং প্রয়োজন নেই; স্বাভাবিক আচরণ কোন বিড ছাড়া একটি প্রতিক্রিয়া ফিরে.

মনে রাখবেন, আপনি যা আশা করতে পারেন তার বিপরীতে, পিং অনুরোধে কোনো বিজ্ঞাপন নেই। এবং, উপরে বিস্তারিত হিসাবে, আপনার একটি পিং অনুরোধে সাড়া দেওয়ার পরে সংযোগটি বন্ধ করা উচিত নয়।

পিয়ারিং বিবেচনা করুন

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

• ইন্টারনেটে, ট্রানজিট লিঙ্কগুলি প্রাথমিকভাবে "হট-প্যাটো রাউটিং" এর মাধ্যমে বেছে নেওয়া হয়, যা আমাদের নেটওয়ার্কের বাইরের সবচেয়ে কাছের লিঙ্কটি খুঁজে পায় যা একটি প্যাকেট তার গন্তব্যে পেতে পারে এবং সেই লিঙ্কের মাধ্যমে প্যাকেটটিকে রুট করে। যখন ট্র্যাফিক একটি প্রদানকারীর মালিকানাধীন মেরুদণ্ডের একটি অংশ অতিক্রম করে যার সাথে আমাদের অনেক পিয়ারিং সংযোগ রয়েছে, নির্বাচিত লিঙ্কটি প্যাকেটটি যেখানে শুরু হয় তার কাছাকাছি হতে পারে। সেই বিন্দুর বাইরে প্যাকেটটি দরদাতার কাছে যে পথ অনুসরণ করে তার কোনো নিয়ন্ত্রণ আমাদের নেই, তাই এটি পথের অন্যান্য স্বায়ত্তশাসিত সিস্টেমে (নেটওয়ার্ক) বাউন্স হতে পারে।

• বিপরীতে, যখন একটি সরাসরি পিয়ারিং চুক্তি হয়, প্যাকেটগুলি সর্বদা একটি পিয়ারিং লিঙ্ক বরাবর পাঠানো হয়। প্যাকেটের উৎপত্তি যেখানেই হোক না কেন, এটি শেয়ার্ড পিয়ারিং পয়েন্টে না পৌঁছানো পর্যন্ত Google-এর মালিকানাধীন বা লিজ দেওয়া লিঙ্কগুলিকে অতিক্রম করে, যা দরদাতার অবস্থানের কাছাকাছি হওয়া উচিত। বিপরীত ট্রিপটি Google নেটওয়ার্কে একটি ছোট হপ দিয়ে শুরু হয় এবং বাকি পথটি Google নেটওয়ার্কে থাকে। Google-পরিচালিত পরিকাঠামোতে বেশিরভাগ ট্রিপ রাখা নিশ্চিত করে যে প্যাকেটটি একটি কম লেটেন্সি রুট নেয় এবং অনেক সম্ভাব্য পরিবর্তনশীলতা এড়ায়।

স্ট্যাটিক DNS জমা দিন

আমরা ক্রেতাদের সবসময় Google-এ একটি একক স্ট্যাটিক ডিএনএস ফলাফল জমা দেওয়ার পরামর্শ দিই এবং ট্রাফিক ডেলিভারি পরিচালনা করতে Google-এর উপর নির্ভর করুন।

ভারসাম্য লোড করার বা উপলব্ধতা পরিচালনা করার সময় দরদাতাদের DNS সার্ভার থেকে দুটি সাধারণ অনুশীলন এখানে রয়েছে:

1. ডিএনএস সার্ভার একটি প্রশ্নের উত্তরে একটি ঠিকানা, বা ঠিকানার একটি উপসেট দেয় এবং তারপরে এই প্রতিক্রিয়ার মধ্য দিয়ে কিছু ফ্যাশনে চলে।
2. ডিএনএস সার্ভার সর্বদা একই সেট অ্যাড্রেস দিয়ে সাড়া দেয়, কিন্তু প্রতিক্রিয়াতে অ্যাড্রেসের ক্রমকে চক্রাকারে চালায়।

প্রথম কৌশলটি লোড ব্যালেন্সিংয়ের ক্ষেত্রে দুর্বল কারণ স্ট্যাকের একাধিক স্তরে প্রচুর ক্যাশিং রয়েছে, এবং ক্যাশিং বাইপাস করার প্রচেষ্টা সম্ভবত পছন্দের ফলাফল পাবে না যেহেতু Google দরদাতার কাছে DNS রেজোলিউশন সময় চার্জ করে।

দ্বিতীয় কৌশলটি মোটেও লোডের ভারসাম্য অর্জন করে না যেহেতু Google এলোমেলোভাবে DNS প্রতিক্রিয়া তালিকা থেকে একটি IP ঠিকানা নির্বাচন করে তাই প্রতিক্রিয়ার ক্রম কোন ব্যাপার না।

যদি একজন দরদাতা একটি DNS পরিবর্তন করে, Google তার DNS রেকর্ডে সেট করা TTL(টাইম-টু-লাইভ) সম্মান করবে, কিন্তু রিফ্রেশ ব্যবধান অনিশ্চিত থাকে।