পারফরম্যান্সের উন্নতি

gzip ব্যবহার করে কম্প্রেশন

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

gzip-এনকোডেড রেসপন্স পেতে হলে আপনাকে দুটি জিনিস করতে হবে: একটি Accept-Encoding হেডার সেট করুন, এবং আপনার ব্যবহারকারী এজেন্টকে gzip স্ট্রিং ধারণ করার জন্য পরিবর্তন করুন। gzip কম্প্রেশন সক্ষম করার জন্য সঠিকভাবে তৈরি HTTP হেডারের একটি উদাহরণ এখানে দেওয়া হল:

Accept-Encoding: gzip
User-Agent: my program (gzip)

আংশিক সম্পদ নিয়ে কাজ করা

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

আংশিক অনুরোধ দুই ধরণের আছে:

• আংশিক প্রতিক্রিয়া : একটি অনুরোধ যেখানে আপনি প্রতিক্রিয়ায় কোন ক্ষেত্রগুলি অন্তর্ভুক্ত করবেন তা নির্দিষ্ট করেন ( fields অনুরোধ প্যারামিটার ব্যবহার করুন)।
• প্যাচ : একটি আপডেট অনুরোধ যেখানে আপনি কেবল সেই ক্ষেত্রগুলি পাঠান যা আপনি পরিবর্তন করতে চান ( PATCH HTTP ক্রিয়া ব্যবহার করুন)।

আংশিক অনুরোধ করার বিষয়ে আরও বিশদ নিম্নলিখিত বিভাগগুলিতে সরবরাহ করা হয়েছে।

আংশিক প্রতিক্রিয়া

ডিফল্টরূপে, সার্ভার অনুরোধ প্রক্রিয়াকরণের পরে একটি রিসোর্সের সম্পূর্ণ প্রতিনিধিত্ব ফেরত পাঠায়। আরও ভালো পারফরম্যান্সের জন্য, আপনি সার্ভারকে শুধুমাত্র আপনার প্রয়োজনীয় ক্ষেত্রগুলি পাঠাতে বলতে পারেন এবং পরিবর্তে একটি আংশিক প্রতিক্রিয়া পেতে পারেন।

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

মনে রাখবেন যে fields প্যারামিটার শুধুমাত্র প্রতিক্রিয়া ডেটাকে প্রভাবিত করে; এটি আপনার প্রয়োজন এমন ডেটাকে প্রভাবিত করে না, যদি থাকে। রিসোর্স পরিবর্তন করার সময় আপনার পাঠানো ডেটার পরিমাণ কমাতে, একটি প্যাচ অনুরোধ ব্যবহার করুন।

প্যাচ (আংশিক আপডেট)

রিসোর্স পরিবর্তন করার সময় আপনি অপ্রয়োজনীয় ডেটা পাঠানো এড়াতে পারেন। শুধুমাত্র আপনার পরিবর্তন করা নির্দিষ্ট ক্ষেত্রগুলির জন্য আপডেট করা ডেটা পাঠাতে, HTTP PATCH ক্রিয়াটি ব্যবহার করুন। এই নথিতে বর্ণিত প্যাচ শব্দার্থবিদ্যা আংশিক আপডেটের পুরানো GData বাস্তবায়নের চেয়ে আলাদা (এবং সহজ)।

নিচের ছোট উদাহরণটি দেখায় যে প্যাচ ব্যবহার করলে কীভাবে একটি ছোট আপডেট করার জন্য আপনার প্রয়োজনীয় ডেটা কমানো যায়।

উদাহরণ

একটি প্যাচের প্রতিক্রিয়া পরিচালনা করা

একটি বৈধ প্যাচ অনুরোধ প্রক্রিয়াকরণের পর, API পরিবর্তিত রিসোর্সের সম্পূর্ণ উপস্থাপনা সহ একটি 200 OK HTTP প্রতিক্রিয়া কোড প্রদান করে। যদি API দ্বারা ETags ব্যবহার করা হয়, তাহলে সার্ভারটি PUT এর মতোই একটি প্যাচ অনুরোধ সফলভাবে প্রক্রিয়াকরণের সময় ETag মান আপডেট করে।

প্যাচ রিকোয়েস্ট সম্পূর্ণ রিসোর্স রিপাের্টেশন ফেরত দেয়, যদি না আপনি fields প্যারামিটার ব্যবহার করে ডেটার পরিমাণ কমিয়ে দেন।

যদি কোনও প্যাচ অনুরোধের ফলে একটি নতুন রিসোর্স স্টেট তৈরি হয় যা সিনট্যাক্টিক বা শব্দার্থিকভাবে অবৈধ হয়, তাহলে সার্ভারটি একটি 400 Bad Request অথবা 422 Unprocessable Entity HTTP স্ট্যাটাস কোড ফেরত পাঠায় এবং রিসোর্স স্টেট অপরিবর্তিত থাকে। উদাহরণস্বরূপ, যদি আপনি একটি প্রয়োজনীয় ক্ষেত্রের মান মুছে ফেলার চেষ্টা করেন, তাহলে সার্ভার একটি ত্রুটি ফেরত পাঠায়।

PATCH HTTP ক্রিয়া সমর্থিত না হলে বিকল্প স্বরলিপি

যদি আপনার ফায়ারওয়াল HTTP PATCH অনুরোধগুলিকে অনুমতি না দেয়, তাহলে একটি HTTP POST অনুরোধ করুন এবং ওভাররাইড হেডারটি PATCH এ সেট করুন, যেমনটি নীচে দেখানো হয়েছে:

POST https://www.googleapis.com/...
X-HTTP-Method-Override: PATCH
...

প্যাচ এবং আপডেটের মধ্যে পার্থক্য

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

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

সংক্ষিপ্ত বিবরণ

আপনার ক্লায়েন্টের তৈরি প্রতিটি HTTP সংযোগের ফলে একটি নির্দিষ্ট পরিমাণ ওভারহেড হয়। Google ড্রাইভ API ব্যাচিং সমর্থন করে, যাতে আপনার ক্লায়েন্ট একটি একক HTTP অনুরোধে একাধিক API কল রাখতে পারে।

আপনি যখন ব্যাচিং ব্যবহার করতে চাইতে পারেন, তার উদাহরণ:

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

প্রতিটি ক্ষেত্রে, প্রতিটি কল আলাদাভাবে পাঠানোর পরিবর্তে, আপনি সেগুলিকে একটি একক HTTP অনুরোধে একত্রিত করতে পারেন। সমস্ত অভ্যন্তরীণ অনুরোধ একই Google API-তে যেতে হবে।

একক ব্যাচ অনুরোধে আপনি ১০০টি কলের মধ্যে সীমাবদ্ধ। যদি আপনাকে এর চেয়ে বেশি কল করতে হয়, তাহলে একাধিক ব্যাচ অনুরোধ ব্যবহার করুন।

দ্রষ্টব্য : গুগল ড্রাইভ এপিআই-এর ব্যাচ সিস্টেম OData ব্যাচ প্রসেসিং সিস্টেমের মতো একই সিনট্যাক্স ব্যবহার করে, তবে শব্দার্থবিদ্যা ভিন্ন।

অতিরিক্ত সীমাবদ্ধতার মধ্যে রয়েছে:

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

ব্যাচের বিবরণ

একটি ব্যাচ রিকোয়েস্টে একাধিক API কল একত্রিত করে একটি HTTP রিকোয়েস্টে পাঠানো হয়, যা API ডিসকভারি ডকুমেন্টে নির্দিষ্ট করা batchPath পাঠানো যেতে পারে। ডিফল্ট পাথ হল /batch/ api_name / api_version । এই বিভাগে ব্যাচ সিনট্যাক্সের বিস্তারিত বর্ণনা করা হয়েছে; পরে, একটি উদাহরণ দেওয়া হল।

দ্রষ্টব্য : একসাথে ব্যাচ করা n অনুরোধের একটি সেট আপনার ব্যবহারের সীমার মধ্যে n অনুরোধ হিসাবে গণনা করা হয়, একটি অনুরোধ হিসাবে নয়। প্রক্রিয়াকরণের আগে ব্যাচ অনুরোধটি অনুরোধের একটি সেটে বিভক্ত করা হয়।

একটি ব্যাচ অনুরোধের ফর্ম্যাট

একটি ব্যাচ রিকোয়েস্ট হল একটি একক স্ট্যান্ডার্ড HTTP রিকোয়েস্ট যাতে একাধিক Google ড্রাইভ API কল থাকে, যা multipart/mixed কন্টেন্ট টাইপ ব্যবহার করে। সেই প্রধান HTTP রিকোয়েস্টের মধ্যে, প্রতিটি অংশে একটি নেস্টেড HTTP রিকোয়েস্ট থাকে।

প্রতিটি অংশ তার নিজস্ব Content-Type: application/http HTTP হেডার দিয়ে শুরু হয়। এতে একটি ঐচ্ছিক Content-ID হেডারও থাকতে পারে। তবে, পার্ট হেডারগুলি কেবল অংশের শুরু চিহ্নিত করার জন্য থাকে; এগুলি নেস্টেড রিকোয়েস্ট থেকে আলাদা। সার্ভার ব্যাচ রিকোয়েস্টটিকে আলাদা রিকোয়েস্টে রূপান্তর করার পরে, পার্ট হেডারগুলি উপেক্ষা করা হয়।

প্রতিটি অংশের মূল অংশ হল একটি সম্পূর্ণ HTTP অনুরোধ, যার নিজস্ব ক্রিয়াপদ, URL, হেডার এবং মূল অংশ রয়েছে। HTTP অনুরোধে শুধুমাত্র URL-এর পাথ অংশ থাকতে হবে; ব্যাচ অনুরোধে সম্পূর্ণ URL অনুমোদিত নয়।

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

উদাহরণস্বরূপ, যদি আপনি একটি নির্দিষ্ট কলের জন্য একটি Authorization হেডার প্রদান করেন, তাহলে সেই হেডারটি শুধুমাত্র সেই কলের জন্য প্রযোজ্য। যদি আপনি বাইরের অনুরোধের জন্য একটি Authorization হেডার প্রদান করেন, তাহলে সেই হেডারটি সমস্ত পৃথক কলের জন্য প্রযোজ্য হবে যদি না তারা তাদের নিজস্ব Authorization হেডার দিয়ে এটিকে ওভাররাইড করে।

যখন সার্ভার ব্যাচ করা অনুরোধটি গ্রহণ করে, তখন এটি প্রতিটি অংশে বাইরের অনুরোধের ক্যোয়ারী প্যারামিটার এবং হেডার (যথাযথভাবে) প্রয়োগ করে এবং তারপর প্রতিটি অংশকে এমনভাবে বিবেচনা করে যেন এটি একটি পৃথক HTTP অনুরোধ।

একটি ব্যাচ অনুরোধের প্রতিক্রিয়া

সার্ভারের প্রতিক্রিয়া হল একটি একক স্ট্যান্ডার্ড HTTP প্রতিক্রিয়া যার একটি multipart/mixed কন্টেন্ট টাইপ রয়েছে; প্রতিটি অংশ হল ব্যাচ করা অনুরোধের মধ্যে থাকা অনুরোধগুলির একটির প্রতিক্রিয়া, অনুরোধগুলির মতো একই ক্রমে।

অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশে একটি সম্পূর্ণ HTTP প্রতিক্রিয়া থাকে, যার মধ্যে একটি স্ট্যাটাস কোড, হেডার এবং বডি থাকে। এবং অনুরোধের অংশগুলির মতো, প্রতিটি প্রতিক্রিয়া অংশের আগে একটি Content-Type হেডার থাকে যা অংশটির শুরু চিহ্নিত করে।

যদি অনুরোধের একটি নির্দিষ্ট অংশে একটি Content-ID হেডার থাকে, তাহলে প্রতিক্রিয়ার সংশ্লিষ্ট অংশে একটি মিলিত Content-ID হেডার থাকবে, যার মূল মানটি স্ট্রিং response- এর আগে থাকবে, যেমনটি নিম্নলিখিত উদাহরণে দেখানো হয়েছে।

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

উদাহরণ

নিম্নলিখিত উদাহরণটি Google ড্রাইভ API এর সাথে ব্যাচিংয়ের ব্যবহার দেখায়।

ব্যাচ অনুরোধের উদাহরণ

POST https://www.googleapis.com/batch/drive/v3
Accept-Encoding: gzip
User-Agent: Google-HTTP-Java-Client/1.20.0 (gzip)
Content-Type: multipart/mixed; boundary=END_OF_PART
Content-Length: 963


--END_OF_PART
Content-Length: 337
Content-Type: application/http
content-id: 1
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id
Authorization: Bearer authorization_token
Content-Length: 70
Content-Type: application/json; charset=UTF-8

{
  "emailAddress":"example@appsrocks.com",
  "role":"writer",
  "type":"user"
}
--END_OF_PART
Content-Length: 353
Content-Type: application/http
content-id: 2
content-transfer-encoding: binary

POST https://www.googleapis.com/drive/v3/files/fileId/permissions?fields=id&sendNotificationEmail=false
Authorization: Bearer authorization_token
Content-Length: 58
Content-Type: application/json; charset=UTF-8

{
   "domain":"appsrocks.com",
   "role":"reader",
   "type":"domain"
}
--END_OF_PART--

ব্যাচ প্রতিক্রিয়ার উদাহরণ

এটি পূর্ববর্তী বিভাগে উদাহরণ অনুরোধের প্রতিক্রিয়া।

HTTP/1.1 200 OK
Alt-Svc: quic=":443"; p="1"; ma=604800
Server: GSE
Alternate-Protocol: 443:quic,p=1
X-Frame-Options: SAMEORIGIN
Content-Encoding: gzip
X-XSS-Protection: 1; mode=block
Content-Type: multipart/mixed; boundary=batch_6VIxXCQbJoQ_AATxy_GgFUk
Transfer-Encoding: chunked
X-Content-Type-Options: nosniff
Date: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Vary: X-Origin
Vary: Origin
Expires: Fri, 13 Nov 2015 19:28:59 GMT


--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-1

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "12218244892818058021i"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk
Content-Type: application/http
Content-ID: response-2

HTTP/1.1 200 OK
Content-Type: application/json; charset=UTF-8
Date: Fri, 13 Nov 2015 19:28:59 GMT
Expires: Fri, 13 Nov 2015 19:28:59 GMT
Cache-Control: private, max-age=0
Content-Length: 35

{
 "id": "04109509152946699072k"
}

--batch_6VIxXCQbJoQ_AATxy_GgFUk--