আপনি Apigee Edge ডকুমেন্টেশন দেখছেন।
Apigee X ডকুমেন্টেশন দেখুন। তথ্য
সমস্যার উপসর্গ
ক্লায়েন্ট অ্যাপ্লিকেশন, API কলের উত্তর হিসেবে 504 HTTP স্ট্যাটাস কোড সহ মেসেজ
Gateway Timeout পায়।
HTTP স্ট্যাটাস কোড - 504 Gateway Timeout সমস্যাটি ইঙ্গিত করে যে ক্লায়েন্ট
API চালানোর সময় Edge Gateway বা ব্যাকএন্ড সার্ভার থেকে সময়মতো উত্তর
পায়নি
সমস্যার মেসেজ
ক্লায়েন্ট অ্যাপ্লিকেশন নিম্নলিখিত রেসপন্স কোড পায়:
HTTP/1.1 504 Gateway Timeout
কিছু ক্ষেত্রে, নিম্নলিখিত সমস্যার মেসেজও দেখা যেতে পারে:
{
"fault": {
"faultstring": "Gateway Timeout",
"detail": {
"errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
}
}
}গেটওয়ে টাইমআউট কেন হয়?
Edge প্ল্যাটফর্মের মাধ্যমে API অনুরোধের সাধারণ পাথ হল ক্লায়েন্ট -> রাউটার -> মেসেজ প্রসেসর -> ব্যাকএন্ড সার্ভার যা নিচের ছবিতে দেখানো হয়েছে:

Edge প্ল্যাটফর্মের মধ্যে ক্লায়েন্ট অ্যাপ্লিকেশন, রাউটার ও মেসেজ প্রসেসর উপযুক্ত টাইমআউট ভ্যালু দিয়ে সেট-আপ করা হয়।
টাইমআউট ভ্যালুর উপর ভিত্তি করে, Edge প্ল্যাটফর্ম প্রতিটি API অনুরোধের জন্য একটি নির্দিষ্ট সময়ের
মধ্যে উত্তর পাঠানোর প্রত্যাশা করে। নির্দিষ্ট সময়সীমার মধ্যে
আপনি উত্তর না পেলে, 504 Gateway Timeout Error রিটার্ন করা হয়।
Edge-এ কখন টাইম-আউট হতে পারে সেই সম্পর্কে নিম্নলিখিত সারণী থেকে আরও তথ্য পাওয়া যায়:
| টাইম-আউট হওয়া | বিবরণ |
|---|---|
| মেসেজ প্রসেসরে টাইম-আউট হয় |
|
| রাউটারে টাইম-আউট হয় |
|
| ক্লায়েন্ট অ্যাপ্লিকেশনে টাইম-আউট হয় |
|
সম্ভাব্য কারণ
Edge-এ, 504 Gateway Timeout সমস্যার সাধারণ কারণগুলি হল:
| কারণ | বিবরণ | এর জন্য দেওয়া ধাপ |
|---|---|---|
| ব্যাকএন্ড সার্ভার ধীরে কাজ করছে | API অনুরোধ প্রসেস করা ব্যাকএন্ড সার্ভারটি খুব বেশি লোড বা খারাপ পারফর্ম্যান্সের কারণে খুব ধীরে কাজ করছে। | পাবলিক ও প্রাইভেট ক্লাউড ব্যবহারকারী |
| Edge-এর মাধ্যমে API অনুরোধ প্রসেস করার গতি কম | Edge-এ অনেক বেশি লোড বা খারাপ পারফর্ম্যান্সের কারণে API অনুরোধ প্রসেস করতে অনেক সময় লাগে। |
ধীরে ব্যাকএন্ড সার্ভার
ব্যাকএন্ড সার্ভার খুব ধীরে কাজ করলে বা API অনুরোধ প্রসেস করতে অনেক সময় নিলে, আপনি
504 Gateway Timeout সমস্যা দেখতে পাবেন। উপরে বর্ণিত বিভাগ অনুযায়ী, নিম্নলিখিত কোনও একটি পরিস্থিতিতে টাইম-আউট
হতে পারে:
- ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই মেসেজ প্রসেসরের টাইম-আউট হয়ে যায়।
- মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই রাউটারের টাইম-আউট হয়ে যায়।
- রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট হয়ে যায়।
নিচের বিভাগে, এই প্রতিটি পরিস্থিতি অনুযায়ী কীভাবে সমস্যা নির্ণয় ও সমাধান করতে হয় তা বর্ণনা করা হয়েছে।
পরিস্থিতি #১ ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই মেসেজ প্রসেসরের টাইম-আউট হয়ে যায়
ডায়াগনসিস
ব্যাকএন্ড সার্ভার ধীর গতির হওয়ার কারণে 504 Gateway Timeout সমস্যা হয়েছে কিনা তা নির্ণয় করতে
আপনি নিম্নলিখিত পদ্ধতি ব্যবহার করতে পারেন।
পদ্ধতি #১ Trace ব্যবহার করে
সমস্যাটি এখনও অ্যাক্টিভ থাকলে (504 সংক্রান্ত সমস্যা এখনও হচ্ছে), তাহলে নিচে উল্লেখ করা
ধাপগুলি অনুসরণ করুন:
- Edge UI-তে প্রভাবিত API ট্রেস করুন। সমস্যা না হওয়া পর্যন্ত অপেক্ষা করুন অথবা আপনার কাছে API কল থাকলে, কিছু API কল করুন এবং
504 Gateway Timeoutসমস্যাটি আবার তৈরি করুন। - সমস্যাটি হওয়ার পরে, সেই নির্দিষ্ট অনুরোধটি পরীক্ষা করুন যেখানে প্রতিক্রিয়া কোড হিসেবে
504দেখানো হয়েছে। - প্রতিটি ধাপে অতিবাহিত সময় চেক করুন এবং যে ধাপে সবচেয়ে বেশি সময় ব্যয় হয়েছে সেটি নোট করে রাখুন।
- নিম্নলিখিত ফেজগুলির মধ্যে কোনও একটির ঠিক পরেই সবচেয়ে বেশি সময় ধরে
ত্রুটিটি দেখতে পেলে, এটি ইঙ্গিত করে যে ব্যাকএন্ড সার্ভার ধীরে কাজ করছে অথবা অনুরোধ প্রসেস করতে
অনেক সময় নিচ্ছে:
- টার্গেট সার্ভারে অনুরোধ পাঠানো হয়েছে
- ServiceCallout নীতি
নিচে একটি স্যাম্পেল ট্রেস দেওয়া হল, যেখানে দেখানো হয়েছে যে ৫৫ সেকেন্ড পরেও ব্যাকএন্ড সার্ভার কোনও উত্তর দেয়নি। এর ফলে 504 Gateway Timeout সমস্যা হয়েছে:

উপরের ট্রেসে, মেসেজ প্রসেসর ৫৫০০২ মিলিসেকেন্ড পরে টাইম-আউট হয়ে যায় কারণ ব্যাকএন্ড সার্ভার কোনও উত্তর দেয় না ।
পদ্ধতি #২ মেসেজ প্রসেসর লগ ব্যবহার করা
- মেসেজ প্রসেসরের লগ চেক করুন
(
/opt/apigee/var/log/edge-message-processor/logs/system.log) -
আপনি যদি নির্দিষ্ট API প্রক্সি অনুরোধের জন্য
Gateway TimeoutএবংonTimeoutReadসমস্যা দেখতে পান নির্দিষ্ট সময়ে, তাহলে এটি ইঙ্গিত করে যে মেসেজ প্রসেসরের টাইম-আউট হয়ে গেছে।গেটওয়ে টাইম-আউট সংক্রান্ত সমস্যা দেখানো স্যাম্পেল মেসেজ প্রসেসর লগ
2015-09-29 20:16:54,340 org:myorg env:staging api:profiles rev:13 NIOThread@1 ERROR ADAPTORS.HTTP.FLOW - AbstractResponseListener.onException() : AbstractResponseListener.onError(HTTPResponse@4d898cf1, Gateway Timeout) 2015-09-29 20:16:57,361 org:myorg env:staging api:profileNewsletters rev:8 NIOThread@0 ERROR HTTP.CLIENT - HTTPClient$Context$3.onTimeout() : SSLClientChannel[C:XX.XX.XX.XX:443 Remote host:192.168.38.54:38302]@120171 useCount=2 bytesRead=0 bytesWritten=824 age=55458ms lastIO=55000ms .onTimeoutRead
উপরের মেসেজ প্রসেসর লগে, আপনি লক্ষ্য করবেন যে IP অ্যাড্রেস XX.XX.XX.XX সহ ব্যাকএন্ড সার্ভারটি ৫৫ সেকেন্ড (lastIO=55000ms) পরেও কোনও উত্তর দেয়নি। এর ফলে, মেসেজ প্রসেসর টাইম-আউট হয়ে গেছে এবং
504 Gateway Timeoutসমস্যা হয়েছে।এটি চেক করুন: মেসেজ প্রসেসরে কীভাবে টাইম-আউট কন্ট্রোল করা হয়?
- Message Processor-এ কীভাবে টাইম-আউট কন্ট্রোল করা হয়। মেসেজ প্রসেসর সাধারণত
প্রপার্টির মাধ্যমে ডিফল্ট টাইমআউট ভ্যালু (৫৫ সেকেন্ড) দিয়ে সেট করা হয়
HTTPTransport.io.timeout.millis। এই টাইমআউট ভ্যালু এই মেসেজ প্রসেসর দ্বারা পরিবেশিত কোনও সংস্থার অন্তর্গত সব API প্রক্সির ক্ষেত্রে প্রযোজ্য।- ব্যাকএন্ড সার্ভার ৫৫ সেকেন্ডের মধ্যে উত্তর না দিলে, মেসেজ
প্রসেসর টাইম-আউট হয়ে যায় এবং ক্লায়েন্টকে
504 Gateway Timeoutএরর পাঠায়।
- ব্যাকএন্ড সার্ভার ৫৫ সেকেন্ডের মধ্যে উত্তর না দিলে, মেসেজ
প্রসেসর টাইম-আউট হয়ে যায় এবং ক্লায়েন্টকে
- মেসেজ প্রসেসরে নির্দিষ্ট করা টাইমআউট ভ্যালু API প্রক্সির মধ্যে নির্দিষ্ট করা
io.timeout.millisপ্রপার্টির মাধ্যমে ওভাররাইড করা যেতে পারে। এই টাইমআউট ভ্যালু নির্দিষ্ট API প্রক্সির ক্ষেত্রে প্রযোজ্য যেখানে উপরে উল্লেখ করা প্রপার্টি নির্দিষ্ট করা আছে। যেমন, API প্রক্সির মধ্যেio.timeout.millis১০ সেকেন্ডে সেট করা থাকলে, এই নির্দিষ্ট API প্রক্সির জন্য ১০ সেকেন্ডের টাইমআউট ভ্যালু ব্যবহার করা হবে।- নির্দিষ্ট
API প্রক্সির জন্য ব্যাকএন্ড সার্ভার ১০ সেকেন্ডের মধ্যে উত্তর না দিলে, মেসেজ প্রসেসর টাইম-আউট হয়ে যায় এবং ক্লায়েন্টকে
504 Gateway Timeoutসমস্যার মেসেজ পাঠায়।
- নির্দিষ্ট
API প্রক্সির জন্য ব্যাকএন্ড সার্ভার ১০ সেকেন্ডের মধ্যে উত্তর না দিলে, মেসেজ প্রসেসর টাইম-আউট হয়ে যায় এবং ক্লায়েন্টকে
- Message Processor-এ কীভাবে টাইম-আউট কন্ট্রোল করা হয়। মেসেজ প্রসেসর সাধারণত
প্রপার্টির মাধ্যমে ডিফল্ট টাইমআউট ভ্যালু (৫৫ সেকেন্ড) দিয়ে সেট করা হয়
রেজোলিউশন
- ব্যাকএন্ড সার্ভার কেন ৫৫ সেকেন্ডের বেশি সময় নিচ্ছে তা চেক করুন এবং দেখুন যে আরও দ্রুত উত্তর দেওয়ার জন্য এটি ঠিক/অপ্টিমাইজ করা যায় কিনা।
- ব্যাকএন্ড সার্ভার ঠিক করা/অপ্টিমাইজ করা সম্ভব না হলে অথবা এটি জানা থাকলে যে ব্যাকএন্ড সার্ভার কনফিগার করা টাইমআউটের থেকে বেশি সময় নেয়, তাহলে উপযুক্ত ভ্যালুতে রাউটার ও মেসেজ প্রসেসরের টাইমআউট ভ্যালু বাড়ান।
পরিস্থিতি #২ - মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই রাউটার টাইম-আউট হয়ে যায়
মেসেজ
প্রসেসর/ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগে রাউটার টাইম-আউট হয়ে গেলে, আপনি 504 Gateway Timeout সমস্যা পেতে পারেন। নিম্নলিখিত কোনও একটি পরিস্থিতিতে এটি হতে পারে:
- রাউটারে সেট করা টাইমআউট ভ্যালু, মেসেজ
প্রসেসরে সেট করা টাইমআউট ভ্যালুর থেকে কম। যেমন, ধরা যাক, রাউটারে টাইমআউট ৫০ সেকেন্ড, যেখানে মেসেজ
প্রসেসরের টাইমআউট ৫৫ সেকেন্ড।
রাউটারে টাইম-আউট মেসেজ প্রসেসরে টাইম-আউট ৫০ সেকেন্ড ৫৫ সেকেন্ড - Message Processor-এর টাইম-আউট ভ্যালু, API Proxy-এর
টার্গেট এন্ডপয়েন্ট কনফিগারেশনের মধ্যে সেট করা
io.timeout.millisপ্রপার্টি ব্যবহার করে একটি বেশি টাইম-আউট ভ্যালু দিয়ে ওভাররাইড করা হয়:যেমন, নিম্নলিখিত টাইমআউট ভ্যালু সেট করা থাকলে:
রাউটারে টাইম-আউট মেসেজ প্রসেসরে টাইম-আউট API প্রক্সির মধ্যে টাইম-আউট ৫৭ সেকেন্ড ৫৫ সেকেন্ড ১২০ সেকেন্ড কিন্তু API প্রক্সিতে
io.timeout.millis১২০ সেকেন্ডে সেট করা আছে:<HTTPTargetConnection> <Properties> <Property name="io.timeout.millis">120000</Property> </Properties> <URL>http://www.apigee.com</URL> </HTTPTargetConnection>এরপরে, মেসেজ প্রসেসর ৫৫ সেকেন্ড পরে টাইম-আউট হবে না, যদিও এর টাইম-আউট ভ্যালু (৫৫ সেকেন্ড) রাউটারে থাকা টাইম-আউট ভ্যালুর (৫৭ সেকেন্ড) থেকে কম। এর কারণ হল, API প্রক্সির মধ্যে সেট করা ১২০ সেকেন্ডের ভ্যালু মেসেজ প্রসেসরের ৫৫ সেকেন্ডের টাইমআউট ভ্যালুকে ওভাররাইড করে। তাই, এই নির্দিষ্ট API প্রক্সির জন্য Message Processor-এর টাইম-আউট ভ্যালু ১২০ সেকেন্ড হবে।
API প্রক্সির মধ্যে ১২০ সেকেন্ড সেট করা থাকলেও, রাউটারের টাইমআউট ভ্যালু কম (৫৭ সেকেন্ড) হওয়ার কারণে, ব্যাকএন্ড সার্ভার ৫৭ সেকেন্ডের মধ্যে উত্তর না দিলে রাউটার টাইমআউট হয়ে যাবে।
ডায়াগনসিস
- NGINX অ্যাক্সেস লগ চেক করুন
(
/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log) -
মেসেজ প্রসেসরের আগে রাউটার টাইম-আউট হয়ে গেলে, নির্দিষ্ট API অনুরোধের জন্য NGINX অ্যাক্সেস লগে
504স্ট্যাটাস দেখতে পাবেন এবং মেসেজ প্রসেসর থেকেmessage id-হিসেবে সেট করা হবে। এর কারণ হল, রাউটারে সেট করা টাইম-আউটের মধ্যে মেসেজ প্রসেসর থেকে রাউটার কোনও উত্তর পায়নি।রাউটার টাইম-আউট হওয়ার কারণে 504 দেখানো হচ্ছে এমন NGINX লগ এন্ট্রি

- উপরের উদাহরণে, NGINX-এ
504-এর স্ট্যাটাস, Message Processor থেকে পাওয়া মেসেজ আইডি হল-এবং মোট সময় লেগেছে ৫৭.০০১ সেকেন্ড। এর কারণ হল, ৫৭.০০১ সেকেন্ড পরে রাউটার টাইম-আউট হয়ে গেছে এবং আমরা মেসেজ প্রসেসর থেকে কোনও উত্তর পাইনি। - এই ক্ষেত্রে, আপনি মেসেজ
প্রসেসর লগে
Broken Pipeব্যতিক্রম দেখতে পাবেন (/opt/apigee/var/log/edge-message-processor/logs/system.log).2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-mp01-18869-23151-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
এই সমস্যাটি দেখানো হয় কারণ রাউটারের টাইম-আউট হয়ে গেলে, এটি মেসেজ প্রসেসরের সাথে কানেকশন বন্ধ করে দেয়।
মেসেজ প্রসেসর প্রসেসিং সম্পূর্ণ করলে, সেটি রাউটারে
উত্তর লেখার চেষ্টা করে। রাউটারের সাথে কানেকশন আগেই বন্ধ হয়ে যাওয়ার কারণে, আপনি মেসেজ প্রসেসরে
Broken Pipe exception দেখতে পাবেন।
উপরে ব্যাখ্যা করা পরিস্থিতিতে এই ব্যতিক্রম দেখা যেতে পারে। তাই, 504 Gateway Timeout সমস্যার আসল
কারণ হল ব্যাকএন্ড সার্ভার উত্তর দিতে বেশি সময় নিচ্ছে
এবং আপনাকে সেই সমস্যার সমাধান করতে হবে।
রেজোলিউশন
- এটি কাস্টম ব্যাকএন্ড সার্ভার হলে, তাহলে
- ব্যাকএন্ড সার্ভার কেন উত্তর দিতে বেশি সময় নিচ্ছে তা চেক করুন এবং দেখুন যে এটি দ্রুত উত্তর দেওয়ার জন্য ঠিক/অপ্টিমাইজ করা যায় কিনা।
- ব্যাকএন্ড সার্ভার ঠিক করা/অপ্টিমাইজ করা সম্ভব না হলে অথবা এটি যদি জানা থাকে যে
ব্যাকএন্ড সার্ভার অনেক সময় নেয়, তাহলে রাউটার ও মেসেজ প্রসেসরের
টাইমআউট ভ্যালু বাড়িয়ে দিন।
আইডিয়া: নিম্নলিখিত ক্রম অনুসারে বিভিন্ন কম্পোনেন্টে টাইম-আউট ভ্যালু সেট করুন:
ক্লায়েন্টে টাইম-আউট > রাউটারে টাইম-আউট > মেসেজে টাইম-আউট প্রসেসর > API প্রক্সির মধ্যে টাইম-আউট
- এটি NodeJS ব্যাকএন্ড সার্ভার হলে, তাহলে:
- NodeJS কোড অন্য কোনও ব্যাকএন্ড সার্ভারে কল করছে কিনা এবং উত্তর দিতে অনেক সময় নিচ্ছে কিনা তা চেক করুন। ব্যাকএন্ড সার্ভার কেন বেশি সময় নিচ্ছে তা চেক করুন এবং উপযুক্তভাবে সমস্যার সমাধান করুন।
- মেসেজ প্রসেসর খুব বেশি সিপিইউ বা মেমরি ব্যবহার করছে কিনা তা চেক করুন:
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
JAVA_HOME/bin/jstack -l PID > FILENAME
- কোনও মেসেজ প্রসেসর যদি খুব বেশি মেমরি ব্যবহার করে থাকে, তাহলে নিম্নলিখিত কমান্ড ব্যবহার করে একটি
হিপ
ডাম্প তৈরি করুন:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- নিচের কমান্ড ব্যবহার করে মেসেজ প্রসেসর রিস্টার্ট করুন। এর ফলে সিপিইউ
ও মেমরি কমে যাওয়া উচিত:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- সমস্যাটি এখনও আছে কিনা তা নিশ্চিত করতে API কল মনিটর করুন।
- Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন এবং
থ্রেড ডাম্প, হিপ ডাম্প ও মেসেজ প্রসেসর লগ
প্রদান করুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log)এর ফলে CPU/মেমরি ব্যবহারের হার বেশি হওয়ার কারণ তদন্ত করতে সুবিধা হবে।
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
এটি চেক করুন: Message Processor-এ NodeJS ব্যাক-এন্ড সার্ভারের জন্য কীভাবে টাইম-আউট কন্ট্রোল করা হয়
|
পরিস্থিতি #৩ - রাউটার/মেসেজ প্রসেসর/ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট হয়ে যায়
ব্যাকএন্ড সার্ভার উত্তর দেওয়ার আগে ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট হয়ে গেলে আপনি 504 Gateway Timeout
সমস্যা পেতে পারেন। এই পরিস্থিতি হতে পারে যদি:
- ক্লায়েন্ট অ্যাপ্লিকেশনে সেট করা টাইমআউট ভ্যালু, রাউটার ও মেসেজ প্রসেসরে সেট করা টাইমআউট ভ্যালুর
চেয়ে কম:
যেমন, নিম্নলিখিত টাইমআউট ভ্যালু সেট করা থাকলে:
ক্লায়েন্টে টাইম-আউট রাউটারে টাইম-আউট মেসেজ প্রসেসরে টাইম-আউট ৫০ সেকেন্ড ৫৭ সেকেন্ড ৫৫ সেকেন্ড এই ক্ষেত্রে, Edge-এর মাধ্যমে API অনুরোধের উত্তর পাওয়ার জন্য মোট উপলভ্য সময় হল <= ৫০ সেকেন্ড। এর মধ্যে API অনুরোধ করার জন্য নেওয়া সময়, Edge (রাউটার, মেসেজ প্রসেসর) দ্বারা অনুরোধ প্রসেস করা, ব্যাকএন্ড সার্ভারে অনুরোধ পাঠানো (প্রযোজ্য হলে), ব্যাকএন্ডের অনুরোধ প্রসেস করা ও উত্তর পাঠানো, Edge-এর উত্তর প্রসেস করা এবং অবশেষে ক্লায়েন্টকে সেটি ফেরত পাঠানো অন্তর্ভুক্ত।
৫০ সেকেন্ডের মধ্যে রাউটার ক্লায়েন্টকে উত্তর না দিলে, ক্লায়েন্ট টাইম-আউট হয়ে যাবে এবং রাউটারের সাথে কানেকশন বন্ধ করে দেবে। ক্লায়েন্ট
504রেসপন্স কোড পাবে।এর ফলে NGINX
499স্ট্যাটাস কোড সেট করবে, যা থেকে বোঝা যাবে যে ক্লায়েন্ট কানেকশন বন্ধ করে দিয়েছে।
ডায়াগনসিস
- রাউটার থেকে উত্তর পাওয়ার আগেই ক্লায়েন্ট অ্যাপ্লিকেশন টাইম-আউট হয়ে গেলে, এটি রাউটারের সাথে কানেকশন
বন্ধ করে দেবে। এই পরিস্থিতিতে, আপনি নির্দিষ্ট API অনুরোধের জন্য NGINX অ্যাক্সেস লগে
৪৯৯ স্ট্যাটাস কোড দেখতে পাবেন।
স্ট্যাটাস কোড ৪৯৯ দেখানো NGINX লগ এন্ট্রির নমুনা

- উপরের উদাহরণে, NGINX-এ
499-এর স্ট্যাটাস এবং মোট সময় অতিবাহিত হয়েছে ৫০.০০১ সেকেন্ড। এর থেকে বোঝা যায় যে ৫০.০০১ সেকেন্ড পরে ক্লায়েন্টের টাইম-আউট হয়ে গেছে। - এই ক্ষেত্রে, আপনি
Broken Pipeমেসেজ প্রসেসর লগে ব্যতিক্রম দেখতে পাবেন (/opt/apigee/var/log/edge-message-processor/logs/system.log).
2017-06-09 00:00:25,886 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception java.io.IOException: Broken pipe occurred while writing to channel ClientOutputChannel(ClientChannel[A:XX.XX.XX.XX:8998 Remote host:YY.YY.YY.YY:51400]@23751 useCount=1 bytesRead=0 bytesWritten=486 age=330465ms lastIO=0ms ) 2017-06-09 00:00:25,887 org:myorg env:test api:myapi-v1 rev:23 messageid:rrt-1-11193-11467656-1 NIOThread@1 INFO HTTP.SERVICE - ExceptionHandler.handleException() : Exception trace: java.io.IOException: Broken pipe at com.apigee.nio.channels.ClientOutputChannel.writePending(ClientOutputChannel.java:51) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.onWrite(OutputChannel.java:116) ~[nio-1.0.0.jar:na] at com.apigee.nio.channels.OutputChannel.write(OutputChannel.java:81) ~[nio-1.0.0.jar:na] … <snipped>
- রাউটার টাইম-আউট হয়ে গেলে, এটি মেসেজ প্রসেসরের সাথে কানেকশন বন্ধ করে দেয়। মেসেজ প্রসেসর
প্রসেসিং সম্পূর্ণ করলে, এটি রাউটারে উত্তর লেখার চেষ্টা করে।
রাউটারের সাথে কানেকশন আগেই বন্ধ হয়ে যাওয়ার কারণে, আপনি মেসেজ প্রসেসরে
Broken Pipe exceptionদেখতে পাবেন। - উপরে ব্যাখ্যা করা পরিস্থিতিতে এই ব্যতিক্রম প্রত্যাশিত। তাই,
504 Gateway Timeoutসমস্যার আসল কারণ হল ব্যাকএন্ড সার্ভার উত্তর দিতে অনেক সময় নিচ্ছে এবং আপনাকে সেই সমস্যা সমাধান করতে হবে।
রেজোলিউশন
- এটি আপনার কাস্টম ব্যাকএন্ড সার্ভার হলে:
- ব্যাকএন্ড সার্ভার চেক করে দেখুন যে কেন এটি উত্তর দিতে ৫৭ সেকেন্ডের বেশি সময় নিচ্ছে এবং দেখুন যে এটি দ্রুত উত্তর দেওয়ার জন্য ঠিক/অপ্টিমাইজ করা যায় কিনা।
- ব্যাকএন্ড সার্ভার ঠিক/অপ্টিমাইজ করা সম্ভব না হলে অথবা আপনি যদি জানেন যে ব্যাকএন্ড সার্ভার ঠিক করতে
অনেক সময় লাগবে, তাহলে রাউটার ও মেসেজ প্রসেসরের টাইম-আউট ভ্যালু বাড়িয়ে
দিন।
আইডিয়া: নিম্নলিখিত ক্রম অনুসারে বিভিন্ন কম্পোনেন্টে টাইম-আউট ভ্যালু সেট করুন:
ক্লায়েন্টে টাইম-আউট > রাউটারে টাইম-আউট > মেসেজে টাইম-আউট প্রসেসর > API প্রক্সির মধ্যে টাইম-আউট
- এটি NodeJS ব্যাকএন্ড হলে, তাহলে:
- NodeJS কোড অন্য কোনও ব্যাকএন্ড সার্ভারে কল করছে কিনা এবং সেটি উত্তর দিতে বেশি সময় নিচ্ছে কিনা তা চেক করুন। সেইসব ব্যাকএন্ড সার্ভার কেন বেশি সময় নিচ্ছে তা চেক করুন।
- মেসেজ প্রসেসর বেশি সিপিইউ বা মেমরি ব্যবহার করছে কিনা তা চেক করুন:
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
JAVA_HOME/bin/jstack -l PID > FILENAME
- কোনও মেসেজ প্রসেসর যদি খুব বেশি মেমরি ব্যবহার করে, তাহলে নিম্নলিখিত কমান্ড ব্যবহার করে
হিপ ডাম্প
জেনারেট করুন:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- নিচের কমান্ড ব্যবহার করে মেসেজ প্রসেসর রিস্টার্ট করুন। এর ফলে সিপিইউ ও মেমরি
ব্যবহার কমে যাবে:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- সমস্যাটি এখনও আছে কিনা তা নিশ্চিত করতে API কল মনিটর করুন।
- Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন এবং
থ্রেড ডাম্প, হিপ ডাম্প ও মেসেজ প্রসেসর লগ
প্রদান করুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log)এর ফলে তারা CPU/মেমরি ব্যবহারের হার বেশি হওয়ার কারণ তদন্ত করতে পারবেন)।
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
রাউটার ও মেসেজ প্রসেসরে টাইমআউট ভ্যালু বাড়ানো
আপনার প্রয়োজনীয়তার উপর নির্ভর করে রাউটার ও মেসেজ প্রসেসরে সেট করার জন্য টাইমআউট ভ্যালু সাবধানে বেছে নিন। অত্যন্ত বেশি টাইমআউট ভ্যালু সেট করবেন না। আপনার সাহায্য প্রয়োজন হলে, Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন।
রাউটার
chown apigee:apigee /opt/apigee/customer/application/router.properties
- রাউটার মেশিনে
/opt/apigee/customer/application/router.propertiesফাইল তৈরি করুন, যদি এটি আগে থেকে না থাকে। - এই ফাইলে নিম্নলিখিত লাইন যোগ করুন:
conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS
যেমন, আপনি যদি ১২০ সেকেন্ডের টাইমআউট ভ্যালু সেট করতে চান, তাহলে এটি এইভাবে সেট করুন: নিম্নলিখিত:
conf_load_balancing_load.balancing.driver.proxy.read.timeout=120
- এই ফাইলের মালিক apigee কিনা তা নিশ্চিত করুন:
- রাউটার রিস্টার্ট করুন:
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
- আপনার একাধিক রাউটার থাকলে, সব রাউটারে উপরের ধাপগুলি রিপিট করুন।
মেসেজ প্রসেসর
- Message Processor মেশিনে
/opt/apigee/customer/application/message-processor.propertiesফাইল তৈরি করুন, যদি এটি আগে থেকে না থাকে। - এই ফাইলে নিম্নলিখিত লাইন যোগ করুন:
conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS
যেমন, আপনি যদি ১২০ সেকেন্ডের টাইমআউট ভ্যালু সেট করতে চান, তাহলে এটি এইভাবে সেট করুন: নিম্নলিখিত:
conf_http_HTTPTransport.io.timeout.millis=120000
- এই ফাইলের মালিক apigee কিনা তা নিশ্চিত করুন:
chown apigee:apigee /opt/apigee/customer/application/message-processor.properties
- মেসেজ প্রসেসর রিস্টার্ট করুন:
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- আপনার একাধিক মেসেজ প্রসেসর থাকলে, সব মেসেজ প্রসেসরের ক্ষেত্রে উপরের ধাপগুলি রিপিট করুন।
আইডিয়া: নিম্নলিখিত ক্রম অনুসারে বিভিন্ন কম্পোনেন্টে টাইমআউট ভ্যালু সেট করুন:ক্লায়েন্টে টাইম-আউট > রাউটারে টাইম-আউট > মেসেজ প্রসেসরে টাইম-আউট > API প্রক্সির মধ্যে টাইম-আউট |
Edge-এর মাধ্যমে API সংক্রান্ত অনুরোধ ধীরে ধীরে প্রসেস করা
Edge খুব ধীরে কাজ করলে এবং/অথবা API অনুরোধ প্রসেস করতে অনেক সময় নিলে, আপনি একটি
504 Gateway Timeout সমস্যা দেখতে পাবেন।
ডায়াগনসিস
- Edge UI-তে প্রভাবিত API ট্রেস করুন।
- সমস্যা না হওয়া পর্যন্ত অপেক্ষা করুন অথবা আপনার কাছে API কল থাকলে, কিছু API কল করুন
এবং
504 Gateway Timeoutসমস্যাটি আবার তৈরি করুন। - মনে রাখবেন, এই ক্ষেত্রে, আপনি Trace-এ একটি সফল উত্তর দেখতে পেতে পারেন।
- রাউটার/ক্লায়েন্ট টাইম-আউট হয়ে যায় কারণ মেসেজ প্রসেসর রাউটার/ক্লায়েন্টে (যেটির টাইম-আউট পিরিয়ড সবচেয়ে কম) নির্দিষ্ট করা টাইম-আউট পিরিয়ডের মধ্যে উত্তর দেয় না। তবে, মেসেজ প্রসেসর অনুরোধ প্রসেস করা চালিয়ে যায় এবং সেটি সফলভাবে সম্পূর্ণ করতে পারে।
- এছাড়াও, মেসেজ প্রসেসর যদি HTTP/HTTPS
ব্যাকএন্ড সার্ভারের সাথে যোগাযোগ করে, তবেই মেসেজ প্রসেসরের
HTTPTransport.io.timeout.millisভ্যালু ট্রিগার হয়। অন্যভাবে বলতে গেলে, API প্রক্সির মধ্যে কোনও নীতি (ServiceCallout নীতি ছাড়া) অনেক বেশি সময় নিলে এই টাইম-আউট ট্রিগার হবে না।
- সমস্যা হওয়ার পরে, সেই নির্দিষ্ট অনুরোধটি পরীক্ষা করুন যেটির সবচেয়ে বেশি অতিক্রান্ত সময় আছে।
- প্রতিটি ধাপে অতিবাহিত সময় চেক করুন এবং যে ধাপে সবচেয়ে বেশি সময় ব্যয় হয়েছে সেটি নোট করে রাখুন।
- আপনি যদি পরিষেবা কলআউট নীতি ছাড়া অন্য কোনও নীতিতে সবচেয়ে বেশি সময় অতিবাহিত হতে দেখেন, তাহলে এটি ইঙ্গিত দেয় যে Edge-এর অনুরোধ প্রসেস করতে অনেক সময় লাগছে।
- JavaScript নীতিতে খুব বেশি সময় অতিবাহিত হওয়ার একটি নমুনা UI ট্রেস এখানে দেওয়া হল:

- উপরের উদাহরণে, আপনি লক্ষ্য করেছেন যে জাভাস্ক্রিপ্ট নীতিটি অস্বাভাবিকভাবে দীর্ঘ সময় নিচ্ছে, যা প্রায় ২৪৫ সেকেন্ড।
রেজোলিউশন
- যে নীতি উত্তর দিতে অনেক সময় নিয়েছে সেটি চেক করুন এবং কোনও কাস্টম কোড থাকলে সেটি চেক করুন যা প্রসেস করতে অনেক সময় লাগতে পারে। এই ধরনের কোনও কোড থাকলে, আপনি শনাক্ত করা কোড ঠিক/অপ্টিমাইজ করতে পারেন কিনা দেখুন।
- প্রসেসিং টাইম বেশি লাগার মতো কোনও কাস্টম কোড না থাকলে, মেসেজ
প্রসেসর বেশি সিপিইউ বা মেমরি ব্যবহার করছে কিনা তা চেক করুন:
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
JAVA_HOME/bin/jstack -l PID > FILENAME
- কোনও মেসেজ প্রসেসরের মেমরি ব্যবহার বেশি হলে, নিম্নলিখিত কমান্ড ব্যবহার করে একটি
হিপ ডাম্প
জেনারেট করুন:
sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID
- নিচের কমান্ড ব্যবহার করে মেসেজ প্রসেসর রিস্টার্ট করুন। এর ফলে সিপিইউ
ও মেমরি ব্যবহার কমে যাবে।
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
- API কল মনিটর করুন এবং সমস্যা এখনও আছে কিনা তা কনফার্ম করুন।
- Apigee Edge সহায়তা টিমের সাথে যোগাযোগ করুন এবং থ্রেড
ডাম্প, হিপ ডাম্প ও মেসেজ প্রসেসর লগ
প্রদান করুন (
/opt/apigee/var/log/edge-message-processor/logs/system.log)এগুলি তাদের অতিরিক্ত CPU/মেমরি ব্যবহারের কারণ তদন্ত করতে সাহায্য করবে)।
- কোনও মেসেজ প্রসেসর খুব বেশি সিপিইউ ব্যবহার করলে, নিম্নলিখিত কমান্ড ব্যবহার করে প্রতি ৩০ সেকেন্ডে তিনটি
থ্রেড
ডাম্প তৈরি করুন:
API মনিটরিং ব্যবহার করে সমস্যার ডায়াগনসিস করা
API মনিটরিং আপনাকে দ্রুত সমস্যার ক্ষেত্রগুলি আলাদা করতে সাহায্য করে যাতে আপনি সমস্যা, পারফর্ম্যান্স ও লেটেন্সি সংক্রান্ত সমস্যা এবং সেগুলির সোর্স ডায়াগনসিস করতে পারেন, যেমন ডেভেলপার অ্যাপ, API প্রক্সি, ব্যাকএন্ড টার্গেট বা API প্ল্যাটফর্ম।
API মনিটরিং ব্যবহার করে আপনার API-তে 5xx সমস্যা কীভাবে সমাধান করবেন তা ডেমোনস্ট্রেট করে এমন একটি নমুনা পরিস্থিতি দেখুন। যেমন, আপনি এমন একটি সতর্কতা সেট-আপ করতে পারেন যাতে ৫০৪ স্ট্যাটাস কোডের সংখ্যা একটি নির্দিষ্ট থ্রেশহোল্ড অতিক্রম করলে আপনাকে বিজ্ঞপ্তি পাঠানো হয়।