504 गेटवे टाइम आउट

आपको Apigee Edge का दस्तावेज़ दिख रहा है.
Apigee X के दस्तावेज़ पर जाएं. जानकारी

समस्या का ब्यौरा

एपीआई कॉल के जवाब के तौर पर, क्लाइंट ऐप्लिकेशन को 504 एचटीटीपी स्टेटस कोड मिलता है. साथ ही, उसे Gateway Timeout मैसेज मिलता है.

एचटीटीपी स्टेटस कोड - 504 Gateway Timeout गड़बड़ी से पता चलता है कि क्लाइंट को एपीआई के एक्ज़ीक्यूशन के दौरान, एज गेटवे या बैकएंड सर्वर से समय पर जवाब नहीं मिला

गड़बड़ी के मैसेज

क्लाइंट ऐप्लिकेशन को यह रिस्पॉन्स कोड मिलता है:

HTTP/1.1 504 Gateway Timeout

कुछ मामलों में, गड़बड़ी का यह मैसेज भी दिख सकता है:

{
   "fault": {
      "faultstring": "Gateway Timeout",
      "detail": {
           "errorcode": "messaging.adaptors.http.flow.GatewayTimeout"
       }
    }
}

गेटवे टाइमआउट किस वजह से होते हैं?

Edge प्लैटफ़ॉर्म के ज़रिए एपीआई अनुरोध का सामान्य पाथ, क्लाइंट -> राउटर -> मैसेज प्रोसेसर -> बैकएंड सर्वर होगा. इसे नीचे दिए गए डायग्राम में दिखाया गया है:

Edge प्लैटफ़ॉर्म में क्लाइंट ऐप्लिकेशन, राऊटर, और मैसेज प्रोसेसर को टाइम आउट की सही वैल्यू के साथ सेट अप किया जाता है. Edge प्लैटफ़ॉर्म, हर एपीआई अनुरोध के लिए एक तय समय में जवाब मिलने की उम्मीद करता है. यह समय, टाइम आउट की वैल्यू पर आधारित होता है. अगर आपको तय समय के अंदर जवाब नहीं मिलता है, तो 504 Gateway Timeout Error दिखता है.

इस टेबल में, Edge में टाइमआउट होने की स्थितियों के बारे में ज़्यादा जानकारी दी गई है:

संभावित कारण

Edge में, 504 Gateway Timeout गड़बड़ी होने की सामान्य वजहें ये हैं:

बैकएंड सर्वर का धीमे काम करना

अगर बैकएंड सर्वर बहुत धीमा है या एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय लेता है, तो आपको 504 Gateway Timeout गड़बड़ी का मैसेज मिलेगा. ऊपर दिए गए सेक्शन में बताया गया है कि टाइम आउट इन स्थितियों में हो सकता है:

1. बैकएंड सर्वर के जवाब देने से पहले, मैसेज प्रोसेसर का समय खत्म हो जाता है.
2. Message Processor/बैकएंड सर्वर के जवाब देने से पहले ही, राऊटर का टाइम आउट हो जाता है.
3. क्लाइंट ऐप्लिकेशन का समय खत्म हो जाता है, लेकिन राउटर/मैसेज प्रोसेसर/बैकएंड सर्वर जवाब नहीं देता.

यहां दिए गए सेक्शन में, इन सभी स्थितियों में समस्या का पता लगाने और उसे हल करने का तरीका बताया गया है.

पहली स्थिति बैकएंड सर्वर से जवाब मिलने से पहले, मैसेज प्रोसेसर का टाइम आउट हो जाता है

संक्रमण की जांच

नीचे दिए गए तरीकों का इस्तेमाल करके, यह पता लगाया जा सकता है कि बैकएंड सर्वर के धीमे होने की वजह से, 504 Gateway Timeout गड़बड़ी हुई है या नहीं.

पहला तरीका: Trace का इस्तेमाल करके

अगर समस्या अब भी बनी हुई है (504 गड़बड़ियां अब भी हो रही हैं), तो यहां दिया गया तरीका अपनाएं:

1. Edge के यूज़र इंटरफ़ेस (यूआई) में, उस एपीआई को ट्रेस करें जिस पर असर पड़ा है. गड़बड़ी होने का इंतज़ार करें या अगर आपके पास एपीआई कॉल है, तो कुछ एपीआई कॉल करें और 504 Gateway Timeout गड़बड़ी को फिर से बनाएं.
2. गड़बड़ी होने के बाद, उस अनुरोध की जांच करें जिसमें रिस्पॉन्स कोड 504 के तौर पर दिखता है.
3. हर फ़ेज़ में लगे समय की जांच करें और उस फ़ेज़ को नोट करें जिसमें सबसे ज़्यादा समय लगा.
4. अगर आपको इनमें से किसी एक फ़ेज़ के तुरंत बाद, सबसे ज़्यादा समय वाली गड़बड़ी दिखती है, तो इसका मतलब है कि बैकएंड सर्वर धीमा है या अनुरोध को प्रोसेस करने में ज़्यादा समय ले रहा है:
   • टारगेट सर्वर को अनुरोध भेजा गया
   • ServiceCallout नीति

यहां एक सैंपल ट्रेस दिया गया है. इसमें दिखाया गया है कि बैकएंड सर्वर ने 55 सेकंड के बाद भी जवाब नहीं दिया. इस वजह से, 504 Gateway Timeout गड़बड़ी हुई:

ऊपर दिए गए ट्रेस में, मैसेज प्रोसेसर 55002 मि॰से॰ के बाद टाइम आउट हो जाता है, क्योंकि बैकएंड सर्वर जवाब नहीं देता.

दूसरी प्रक्रिया: मैसेज प्रोसेसर के लॉग का इस्तेमाल करना

1. मैसेज प्रोसेसर के लॉग की जांच करें (/opt/apigee/var/log/edge-message-processor/logs/system.log)

2. अगर आपको किसी खास एपीआई प्रॉक्सी अनुरोध के लिए, किसी खास समय पर 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

   ऊपर दिए गए मैसेज प्रोसेसर लॉग में, आपको दिखेगा कि XX.XX.XX.XX आईपी पते से दिखाए गए बैकएंड सर्वर ने 55 सेकंड के बाद भी जवाब नहीं दिया (lastIO=55000ms). इस वजह से, मैसेज प्रोसेसर का समय खत्म हो गया और उसने 504 Gateway Timeout गड़बड़ी भेजी.

   यह लेख पढ़ें: मैसेज प्रोसेसर पर टाइम आउट को कैसे कंट्रोल किया जाता है? मैसेज प्रोसेसर पर टाइम आउट को कैसे कंट्रोल किया जाता है. मैसेज प्रोसेसर को आम तौर पर, HTTPTransport.io.timeout.millis प्रॉपर्टी के ज़रिए 55 सेकंड की डिफ़ॉल्ट टाइमआउट वैल्यू के साथ सेट किया जाता है. टाइम आउट होने की यह वैल्यू, उन सभी एपीआई प्रॉक्सी पर लागू होती है जो इस मैसेज प्रोसेसर की सेवा पाने वाले संगठन से जुड़ी हैं. अगर बैकएंड सर्वर 55 सेकंड के अंदर जवाब नहीं देता है, तो Message Processor का समय खत्म हो जाता है और वह क्लाइंट को 504 Gateway Timeout गड़बड़ी भेजता है. मैसेज प्रोसेसर में तय की गई टाइम आउट वैल्यू को, एपीआई प्रॉक्सी में तय की गई प्रॉपर्टी io.timeout.millis से बदला जा सकता है. टाइम आउट की यह वैल्यू, उस एपीआई प्रॉक्सी पर लागू होती है जिसमें ऊपर बताई गई प्रॉपर्टी तय की गई है. उदाहरण के लिए, अगर एपीआई प्रॉक्सी में io.timeout.millis को 10 सेकंड पर सेट किया गया है, तो इस एपीआई प्रॉक्सी के लिए टाइम आउट की वैल्यू 10 सेकंड का इस्तेमाल किया जाएगा. अगर बैकएंड सर्वर, किसी खास एपीआई प्रॉक्सी के लिए 10 सेकंड के अंदर जवाब नहीं देता है, तो मैसेज प्रोसेसर का समय खत्म हो जाता है. इसके बाद, वह क्लाइंट को 504 Gateway Timeout गड़बड़ी का मैसेज भेजता है.

रिज़ॉल्यूशन

1. देखें कि बैकएंड सर्वर को 55 सेकंड से ज़्यादा समय क्यों लग रहा है. साथ ही, देखें कि क्या इसे ठीक किया जा सकता है या तेज़ी से जवाब देने के लिए ऑप्टिमाइज़ किया जा सकता है.
2. अगर बैकएंड सर्वर को ठीक/ऑप्टिमाइज़ नहीं किया जा सकता या यह पता है कि बैकएंड सर्वर, कॉन्फ़िगर किए गए टाइम आउट से ज़्यादा समय लेता है, तो राऊटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू को बढ़ाकर सही वैल्यू पर सेट करें.

स्थिति #2 - मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले ही, राऊटर का टाइम आउट हो जाता है

अगर मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले ही राउटर का टाइम आउट हो जाता है, तो आपको 504 Gateway Timeout गड़बड़ियां मिल सकती हैं. ऐसा इन वजहों से हो सकता है:

• राउटर पर सेट की गई टाइम आउट वैल्यू, Message Processor पर सेट की गई टाइम आउट वैल्यू से कम है. उदाहरण के लिए, मान लें कि Router पर टाइमआउट 50 सेकंड है, जबकि Message Processor पर 55 सेकंड है.

  राऊटर पर टाइम आउट	मैसेज प्रोसेसर का टाइम आउट हो गया है
  50 सेकंड	55 सेकंड

• इस उदाहरण में, Message Processor पर टाइम आउट की वैल्यू को, एपीआई प्रॉक्सी के टारगेट एंडपॉइंट कॉन्फ़िगरेशन में सेट की गई io.timeout.millis प्रॉपर्टी का इस्तेमाल करके, टाइम आउट की ज़्यादा वैल्यू से बदला गया है:

  उदाहरण के लिए, अगर टाइम आउट की ये वैल्यू सेट की गई हैं:

  राऊटर पर टाइम आउट	मैसेज प्रोसेसर का टाइम आउट हो गया है	एपीआई प्रॉक्सी में टाइम आउट
  57 सेकंड	55 सेकंड	120 सेकंड

  हालांकि, एपीआई प्रॉक्सी में io.timeout.millis को 120 सेकंड पर सेट किया गया है:

  <HTTPTargetConnection>
       <Properties>
            <Property name="io.timeout.millis">120000</Property>
        </Properties>
        <URL>http://www.apigee.com</URL>
  </HTTPTargetConnection>

  इसके बाद, मैसेज प्रोसेसर 55 सेकंड के बाद भी टाइम आउट नहीं होगा. भले ही, इसकी टाइमआउट वैल्यू (55 सेकंड) राउटर की टाइमआउट वैल्यू (57 सेकंड) से कम हो. ऐसा इसलिए है, क्योंकि मैसेज प्रोसेसर पर 55 सेकंड की टाइम आउट वैल्यू को एपीआई प्रॉक्सी में सेट की गई 120 सेकंड की वैल्यू से बदल दिया जाता है. इसलिए, इस एपीआई प्रॉक्सी के लिए, Message Processor का टाइम आउट होने का समय 120 सेकंड होगा.

  राउटर के लिए टाइम आउट की वैल्यू, एपीआई प्रॉक्सी में सेट की गई 120 सेकंड की वैल्यू से कम (57 सेकंड) है. इसलिए, अगर बैकएंड सर्वर 57 सेकंड के बाद भी जवाब नहीं देता है, तो राउटर टाइम आउट हो जाएगा.

संक्रमण की जांच

1. NGINX ऐक्सेस लॉग की जांच करें (/opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log)

2. अगर मैसेज प्रोसेसर से पहले राउटर का टाइम आउट हो जाता है, तो आपको किसी खास एपीआई अनुरोध के लिए NGINX ऐक्सेस लॉग पर 504 स्टेटस दिखेगा. साथ ही, मैसेज प्रोसेसर से message id को - के तौर पर सेट किया जाएगा. ऐसा इसलिए होता है, क्योंकि राउटर पर सेट किए गए टाइम आउट की अवधि में, राउटर को मैसेज प्रोसेसर से कोई जवाब नहीं मिला.

   राउटर का समय खत्म होने की वजह से, 504 कोड वाली गड़बड़ी दिखाने वाली NGINX लॉग एंट्री का सैंपल

   

3. ऊपर दिए गए उदाहरण में, NGINX पर 504 का स्टेटस देखें. मैसेज प्रोसेसर से मैसेज आईडी - है और कुल समय 57.001 सेकंड है. ऐसा इसलिए हुआ, क्योंकि राउटर 57.001 सेकंड के बाद टाइम आउट हो गया और हमें मैसेज प्रोसेसर से कोई जवाब नहीं मिला.
4. इस मामले में, आपको मैसेज प्रोसेसर के लॉग (/opt/apigee/var/log/edge-message-processor/logs/system.log).Broken Pipe

   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 गड़बड़ी की असली वजह अब भी बैकएंड सर्वर को जवाब देने में ज़्यादा समय लगना है. आपको इस समस्या को ठीक करना होगा.

रिज़ॉल्यूशन

1. अगर यह कस्टम बैकएंड सर्वर है, तो
   1. देखें कि बैकएंड सर्वर को जवाब देने में इतना समय क्यों लग रहा है. साथ ही, देखें कि क्या इसे ठीक किया जा सकता है या तेज़ी से जवाब देने के लिए ऑप्टिमाइज़ किया जा सकता है.
   2. अगर बैकएंड सर्वर को ठीक/ऑप्टिमाइज़ नहीं किया जा सकता या यह पता है कि बैकएंड सर्वर को ज़्यादा समय लगता है, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू बढ़ाएं.

      सुझाव: यहां दिए गए क्रम में, अलग-अलग कॉम्पोनेंट के लिए टाइम आउट वैल्यू सेट करें: क्लाइंट पर टाइम आउट > राउटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट

2. अगर यह NodeJS बैकएंड सर्वर है, तो:
   1. देखें कि NodeJS कोड, किसी अन्य बैकएंड सर्वर को कॉल कर रहा है या नहीं. साथ ही, यह भी देखें कि जवाब देने में ज़्यादा समय तो नहीं लग रहा है. देखें कि बैकएंड सर्वर को ज़्यादा समय क्यों लग रहा है और समस्या को ठीक करें.
   2. देखें कि मैसेज प्रोसेसर में सीपीयू या मेमोरी का इस्तेमाल ज़्यादा तो नहीं हो रहा है:
      1. अगर किसी मैसेज प्रोसेसर में सीपीयू का इस्तेमाल ज़्यादा हो रहा है, तो यहां दी गई कमांड का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. अगर किसी मैसेज प्रोसेसर में मेमोरी का इस्तेमाल ज़्यादा हो रहा है, तो यहां दिए गए निर्देश का इस्तेमाल करके हीप डंप जनरेट करें:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को फिर से शुरू करें. इससे सीपीयू और मेमोरी का इस्तेमाल कम होना चाहिए:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. एपीआई कॉल को मॉनिटर करें. इससे यह पुष्टि की जा सकेगी कि समस्या अब भी मौजूद है या नहीं.
      5. Apigee Edge की सहायता टीम से संपर्क करें और थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर के लॉग उपलब्ध कराएं. /opt/apigee/var/log/edge-message-processor/logs/system.log)इनसे, ज़्यादा सीपीयू/मेमोरी का इस्तेमाल होने की वजह का पता लगाने में मदद मिलेगी.

तीसरा उदाहरण - क्लाइंट ऐप्लिकेशन का टाइम आउट हो जाता है, लेकिन राउटर/मैसेज प्रोसेसर/बैकएंड सर्वर जवाब नहीं देता है

अगर बैकएंड सर्वर के जवाब देने से पहले क्लाइंट ऐप्लिकेशन का समय खत्म हो जाता है, तो आपको 504 Gateway Timeout गड़बड़ियां दिख सकती हैं. ऐसा तब हो सकता है, जब:

1. क्लाइंट ऐप्लिकेशन पर सेट की गई टाइम आउट वैल्यू, राउटर और मैसेज प्रोसेसर पर सेट की गई टाइम आउट वैल्यू से कम है:

   उदाहरण के लिए, अगर टाइम आउट की ये वैल्यू सेट की गई हैं:

   क्लाइंट पर टाइम आउट	राऊटर पर टाइम आउट	मैसेज प्रोसेसर का टाइम आउट हो गया है
   50 सेकंड	57 सेकंड	55 सेकंड

   इस मामले में, Edge के ज़रिए एपीआई अनुरोध का जवाब पाने के लिए, कुल समय <= 50 सेकंड उपलब्ध है. इसमें एपीआई अनुरोध करने में लगने वाला समय, Edge (राउटर, मैसेज प्रोसेसर) से अनुरोध प्रोसेस होने में लगने वाला समय, बैकएंड सर्वर को अनुरोध भेजने में लगने वाला समय (अगर लागू हो), बैकएंड से अनुरोध प्रोसेस होने और जवाब भेजने में लगने वाला समय, Edge से जवाब प्रोसेस होने और आखिर में क्लाइंट को वापस भेजने में लगने वाला समय शामिल है.

   अगर राऊटर, क्लाइंट को 50 सेकंड के अंदर जवाब नहीं देता है, तो क्लाइंट का कनेक्शन राऊटर से बंद हो जाएगा. क्लाइंट को 504 का रिस्पॉन्स कोड मिलेगा.

   इससे NGINX, स्टेटस कोड 499 सेट करेगा. इससे पता चलेगा कि क्लाइंट ने कनेक्शन बंद कर दिया है.

संक्रमण की जांच

1. अगर क्लाइंट ऐप्लिकेशन को राउटर से जवाब मिलने से पहले ही टाइम आउट हो जाता है, तो वह राउटर से कनेक्शन बंद कर देगा. इस स्थिति में, आपको किसी खास एपीआई अनुरोध के लिए NGINX ऐक्सेस लॉग में 499 स्टेटस कोड दिखेगा.

   NGINX के लॉग की एंट्री का सैंपल, जिसमें स्टेटस कोड 499 दिखाया गया है
   
   

2. ऊपर दिए गए उदाहरण में ध्यान दें कि NGINX पर 499 की स्थिति और कुल समय 50.001 सेकंड है. इससे पता चलता है कि क्लाइंट का टाइम आउट 50.001 सेकंड के बाद हुआ.
3. इस मामले में, आपको मैसेज प्रोसेसर के लॉग में 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>

4. राउटर का टाइम आउट होने के बाद, यह मैसेज प्रोसेसर से कनेक्शन बंद कर देता है. जब मैसेज प्रोसेसर, मैसेज को प्रोसेस कर लेता है, तो वह जवाब को राउटर पर लिखने की कोशिश करता है. राऊटर से कनेक्शन पहले ही बंद हो चुका है. इसलिए, आपको मैसेज प्रोसेसर पर Broken Pipe exception दिखता है.
5. ऊपर बताई गई स्थितियों में, इस अपवाद के होने की उम्मीद है. इसलिए, 504 Gateway Timeout गड़बड़ी की असली वजह अब भी यही है कि बैकएंड सर्वर को जवाब देने में बहुत समय लगता है. आपको इस समस्या को ठीक करना होगा.

रिज़ॉल्यूशन

1. अगर यह आपका कस्टम बैकएंड सर्वर है, तो:
   1. बैकएंड सर्वर की जांच करें. इससे यह पता चलेगा कि सर्वर को 57 सेकंड से ज़्यादा समय क्यों लग रहा है. साथ ही, यह भी पता चलेगा कि क्या सर्वर को ठीक किया जा सकता है या उसे ऑप्टिमाइज़ किया जा सकता है, ताकि वह तेज़ी से जवाब दे सके.
   2. अगर बैकएंड सर्वर को ठीक/ऑप्टिमाइज़ नहीं किया जा सकता या आपको पता है कि बैकएंड सर्वर को ठीक होने में ज़्यादा समय लगेगा, तो राउटर और मैसेज प्रोसेसर पर टाइम आउट की वैल्यू बढ़ाएं.
      
      

      सुझाव: यहां दिए गए क्रम में, अलग-अलग कॉम्पोनेंट के लिए टाइम आउट वैल्यू सेट करें: क्लाइंट पर टाइम आउट > राउटर पर टाइम आउट > मैसेज प्रोसेसर पर टाइम आउट > एपीआई प्रॉक्सी में टाइम आउट

2. अगर यह NodeJS बैकएंड है, तो:
   1. देखें कि क्या NodeJS कोड, किसी अन्य बैकएंड सर्वर को कॉल करता है और क्या उसे जवाब मिलने में ज़्यादा समय लग रहा है. देखें कि उन बैकएंड सर्वर को ज़्यादा समय क्यों लग रहा है.
   2. देखें कि मैसेज प्रोसेसर में सीपीयू या मेमोरी का इस्तेमाल ज़्यादा तो नहीं हो रहा है:
      1. अगर किसी मैसेज प्रोसेसर में सीपीयू का इस्तेमाल ज़्यादा हो रहा है, तो यहां दी गई कमांड का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:

         JAVA_HOME/bin/jstack -l PID > FILENAME

      2. अगर किसी मैसेज प्रोसेसर में मेमोरी का इस्तेमाल ज़्यादा हो रहा है, तो यहां दिए गए निर्देश का इस्तेमाल करके हीप डंप जनरेट करें:

         sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

      3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को फिर से शुरू करें. इससे सीपीयू और मेमोरी का इस्तेमाल कम हो जाएगा:

         /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

      4. एपीआई कॉल को मॉनिटर करें. इससे यह पुष्टि की जा सकेगी कि समस्या अब भी मौजूद है या नहीं.
      5. Apigee Edge की सहायता टीम से संपर्क करें और उन्हें थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर के लॉग दें /opt/apigee/var/log/edge-message-processor/logs/system.log)ताकि उन्हें ज़्यादा सीपीयू/मेमोरी का इस्तेमाल होने की वजह का पता लगाने में मदद मिल सके.

Router और Message Processor पर टाइम आउट की वैल्यू बढ़ाएं

अपनी ज़रूरतों के हिसाब से, Router और Message Processor पर सेट की जाने वाली टाइम आउट वैल्यू को ध्यान से चुनें. टाइम आउट की वैल्यू बहुत ज़्यादा सेट न करें. अगर आपको मदद चाहिए, तो Apigee Edge की सहायता टीम से संपर्क करें.

राऊटर

chown apigee:apigee /opt/apigee/customer/application/router.properties

1. अगर राऊटर मशीन पर /opt/apigee/customer/application/router.properties फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं.
2. इस फ़ाइल में यह लाइन जोड़ें:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=TIME_IN_SECONDS

   उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड पर सेट करनी है, तो इसे इस तरह सेट करें:

   conf_load_balancing_load.balancing.driver.proxy.read.timeout=120

3. पक्का करें कि इस फ़ाइल का मालिकाना हक apigee के पास हो:
4. राऊटर को रीस्टार्ट करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

5. अगर आपके पास एक से ज़्यादा राऊटर हैं, तो ऊपर दिया गया तरीका सभी राऊटर पर दोहराएं.

मैसेज प्रोसेसर

1. अगर Message Processor मशीन पर /opt/apigee/customer/application/message-processor.properties फ़ाइल पहले से मौजूद नहीं है, तो उसे बनाएं.
2. इस फ़ाइल में यह लाइन जोड़ें:

   conf_http_HTTPTransport.io.timeout.millis=TIME_IN_MILLISECONDS

   उदाहरण के लिए, अगर आपको टाइम आउट की वैल्यू 120 सेकंड पर सेट करनी है, तो इसे इस तरह सेट करें:

   conf_http_HTTPTransport.io.timeout.millis=120000

3. पक्का करें कि इस फ़ाइल का मालिकाना हक apigee के पास हो:

   chown apigee:apigee /opt/apigee/customer/application/message-processor.properties

4. मैसेज प्रोसेसर को रीस्टार्ट करें:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

5. अगर आपके पास एक से ज़्यादा मैसेज प्रोसेसर हैं, तो ऊपर दिया गया तरीका सभी मैसेज प्रोसेसर पर दोहराएं.

Edge की ओर से एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है

अगर Edge बहुत धीमा है और/या एपीआई अनुरोध को प्रोसेस करने में ज़्यादा समय ले रहा है, तो आपको 504 Gateway Timeout गड़बड़ी का मैसेज मिलेगा.

संक्रमण की जांच

1. Edge के यूज़र इंटरफ़ेस (यूआई) में, उस एपीआई को ट्रेस करें जिस पर असर पड़ा है.
2. गड़बड़ी होने का इंतज़ार करें. अगर आपके पास एपीआई कॉल है, तो कुछ एपीआई कॉल करें और 504 Gateway Timeout गड़बड़ी को फिर से जनरेट करें.
3. ध्यान दें कि इस मामले में, आपको ट्रेस में एक सही जवाब दिख सकता है.
   1. राउटर/क्लाइंट का समय खत्म हो जाता है, क्योंकि मैसेज प्रोसेसर, राउटर/क्लाइंट पर तय की गई समयसीमा के अंदर जवाब नहीं देता. यह समयसीमा, राउटर/क्लाइंट में से जिसकी भी कम होती है उसके हिसाब से तय की जाती है. हालांकि, मैसेज प्रोसेसर अनुरोध को प्रोसेस करता रहता है और हो सकता है कि वह इसे पूरा कर दे.
   2. इसके अलावा, Message Processor पर सेट की गई HTTPTransport.io.timeout.millis वैल्यू सिर्फ़ तब ट्रिगर होती है, जब Message Processor, एचटीटीपी/एचटीटीपीएस बैकएंड सर्वर से कम्यूनिकेट करता है. दूसरे शब्दों में कहें, तो अगर एपीआई प्रॉक्सी में मौजूद कोई नीति (ServiceCallout नीति के अलावा) लागू होने में ज़्यादा समय ले रही है, तो यह टाइम आउट ट्रिगर नहीं होगा.
4. गड़बड़ी होने के बाद, उस अनुरोध की जांच करें जिसे पूरा होने में सबसे ज़्यादा समय लगा है.
5. हर फ़ेज़ में लगे समय की जांच करें और उस फ़ेज़ को नोट करें जिसमें सबसे ज़्यादा समय लगा है.
6. अगर आपको सेवा के बारे में जानकारी देने वाली सुविधा की नीति के अलावा, किसी अन्य नीति में सबसे ज़्यादा समय दिखता है, तो इसका मतलब है कि Edge को अनुरोध को प्रोसेस करने में ज़्यादा समय लग रहा है.
7. यहां यूज़र इंटरफ़ेस (यूआई) ट्रेस का एक सैंपल दिया गया है. इसमें JavaScript की नीति के लिए, बहुत ज़्यादा समय दिखाया गया है:

   

8. ऊपर दिए गए उदाहरण में, आपको पता चलता है कि JavaScript नीति को लागू होने में बहुत ज़्यादा समय लगा है. इसमें ~ 245 सेकंड लगे हैं.

रिज़ॉल्यूशन

1. देखें कि क्या कोई ऐसी नीति है जिसके जवाब में ज़्यादा समय लगा है. साथ ही, देखें कि क्या कोई ऐसा कस्टम कोड है जिसे प्रोसेस करने में ज़्यादा समय लग सकता है. अगर ऐसा कोई कोड है, तो देखें कि क्या पहचाने गए कोड को ठीक/ऑप्टिमाइज़ किया जा सकता है.
2. अगर कोई ऐसा कस्टम कोड नहीं है जिसकी वजह से प्रोसेसिंग में ज़्यादा समय लग रहा है, तो देखें कि मैसेज प्रोसेसर में सीपीयू या मेमोरी का इस्तेमाल ज़्यादा तो नहीं हो रहा है:
   1. अगर किसी मैसेज प्रोसेसर में सीपीयू का इस्तेमाल ज़्यादा हो रहा है, तो यहां दी गई कमांड का इस्तेमाल करके, हर 30 सेकंड में तीन थ्रेड डंप जनरेट करें:

      JAVA_HOME/bin/jstack -l PID > FILENAME

   2. अगर किसी मैसेज प्रोसेसर में मेमोरी का इस्तेमाल ज़्यादा हो रहा है, तो यहां दिए गए निर्देश का इस्तेमाल करके, हीप डंप जनरेट करें:

      sudo -u apigee JAVA_HOME/bin/jmap -dump:live,format=b,file=FILENAME PID

   3. नीचे दिए गए निर्देश का इस्तेमाल करके, मैसेज प्रोसेसर को फिर से शुरू करें. इससे सीपीयू और मेमोरी का इस्तेमाल कम हो जाएगा.

      /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

   4. एपीआई कॉल पर नज़र रखें और पुष्टि करें कि समस्या अब भी मौजूद है या नहीं.
   5. Apigee Edge की सहायता टीम से संपर्क करें और उन्हें थ्रेड डंप, हीप डंप, और मैसेज प्रोसेसर के लॉग दें /opt/apigee/var/log/edge-message-processor/logs/system.log)ताकि उन्हें ज़्यादा सीपीयू/मेमोरी का इस्तेमाल होने की वजह का पता लगाने में मदद मिल सके.

एपीआई मॉनिटरिंग का इस्तेमाल करके समस्याओं का पता लगाना

एपीआई मॉनिटरिंग की मदद से, गड़बड़ी, परफ़ॉर्मेंस, और लोड होने में लगने वाले समय की समस्याओं और उनके सोर्स का पता लगाया जा सकता है. जैसे, डेवलपर ऐप्लिकेशन, एपीआई प्रॉक्सी, बैकएंड टारगेट या एपीआई प्लैटफ़ॉर्म.

एक सैंपल परिदृश्य देखें, जिसमें एपीआई मॉनिटरिंग का इस्तेमाल करके, अपने एपीआई से जुड़ी 5xx समस्याओं को हल करने का तरीका बताया गया है. उदाहरण के लिए, हो सकता है कि आपको ऐसी सूचना सेट अप करनी हो जो 504 स्टेटस कोड की संख्या किसी थ्रेशोल्ड से ज़्यादा होने पर आपको सूचना दे.