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. मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले राऊटर का समय खत्म हो जाता है.
3. राऊटर/मैसेज प्रोसेसर/बैकएंड सर्वर के जवाब देने से पहले क्लाइंट ऐप्लिकेशन का समय खत्म हो जाता है.

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

स्थिति #1 बैकएंड सर्वर के जवाब देने से पहले, मैसेज प्रोसेसर का समय खत्म हो जाता है

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

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

ट्रेस का इस्तेमाल करके #1 प्रक्रिया

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

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

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

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

प्रक्रिया #2 मैसेज प्रोसेसर लॉग का इस्तेमाल करना

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 गड़बड़ी मिली.

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

रिज़ॉल्यूशन

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

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

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

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

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

• संदेश प्रोसेसर पर टाइम आउट मान को इसका उपयोग करके उच्च टाइमआउट मान से ओवरराइड किया जाता है टारगेट एंडपॉइंट कॉन्फ़िगरेशन में सेट की गई 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 सेकंड, जो एपीआई प्रॉक्सी में सेट होता है. इसलिए, मैसेज प्रोसेसर की टाइम आउट वैल्यू इस खास एपीआई प्रॉक्सी के लिए, यह 120 सेकंड का होगा.

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

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

1. NGINX ऐक्सेस लॉग देखना /opt/apigee/var/log/edge-router/nginx/ORG~ENV.PORT#_access_log

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

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

   

3. ऊपर दिए गए उदाहरण में, मैसेज के मैसेज आईडी, NGINX पर 504 की स्थिति देखें प्रोसेसर - है और बीता हुआ कुल समय 57.001 सेकंड है. इसकी वजह यह है कि राऊटर का समय खत्म हो गया 57.001 सेकंड के बाद और हमें मैसेज प्रोसेसर से कोई जवाब नहीं मिला.
4. इस मामले में, आपको मैसेज में 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 गड़बड़ी की वजह, अब भी बैकएंड सर्वर को जवाब देने में ज़्यादा समय लग रहा है और आपको उस समस्या को हल करना होगा.

रिज़ॉल्यूशन

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

      आइडिया: नीचे दिए गए अलग-अलग कॉम्पोनेंट पर टाइम आउट मान सेट करें क्रम: क्लाइंट पर समय खत्म हुआ > राऊटर पर टाइम आउट हो गया > मैसेज का समय खत्म हो गया प्रोसेसर > एपीआई प्रॉक्सी में टाइम आउट होना

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

         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)मदद के लिए सीपीयू/मेमोरी के ज़्यादा इस्तेमाल की वजह की जांच करें.

स्थिति #3 - राऊटर/मैसेज प्रोसेसर/बैकएंड सर्वर से पहले क्लाइंट से मिले आवेदन का समय खत्म हो गया जवाब देता है

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

1. क्लाइंट ऐप्लिकेशन पर सेट किया गया टाइम आउट मान राऊटर और मैसेज प्रोसेसर:

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

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

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

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

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

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

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

   स्टेटस कोड 499 दिखाने वाले NGINX लॉग की एंट्री का सैंपल
   
   

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. अगर किसी मैसेज प्रोसेसर को सीपीयू के ज़्यादा इस्तेमाल का सामना करना पड़ रहा है, तो तीन जनरेट करें थ्रेड डंप:

         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)की मदद के लिए सीपीयू/मेमोरी के ज़्यादा इस्तेमाल की वजह की जांच करें.

इस पर टाइम आउट मान बढ़ाएं राऊटर और मैसेज प्रोसेसर

राऊटर और मैसेज प्रोसेसर पर सेट की जाने वाली टाइम आउट वैल्यू को ध्यान से चुनें. ऐसा करते समय, राऊटर की सेटिंग के हिसाब से आपकी ज़रूरतें पूरी करता है. तय समय में ज़्यादा देर तक वैल्यू सेट न करें. अगर आपको मदद चाहिए, तो संपर्क करें 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. /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. इसके अलावा, HTTPTransport.io.timeout.millis वैल्यू को मैसेज प्रोसेसर सिर्फ़ तब ट्रिगर होता है, जब मैसेज प्रोसेसर किसी एचटीटीपी/एचटीटीपीएस के साथ संपर्क करता है बैकएंड सर्वर. दूसरे शब्दों में, जब कोई नीति (अन्य नीति) लागू होती है, तब यह टाइम आउट ट्रिगर नहीं होगा सेवाकॉलआउट नीति की तुलना में) एपीआई प्रॉक्सी में ज़्यादा समय लग रहा है.
4. गड़बड़ी आने के बाद, उस अनुरोध की जांच करें जिसमें सबसे लंबा बीता हुआ समय.
5. हर चरण में बीता हुआ समय देखें और उस चरण को नोट करें जहां सबसे ज़्यादा समय है खर्च किया.
6. अगर आपको सेवा के अलावा किसी दूसरी नीति में सबसे ज़्यादा समय बीतने की जानकारी दिख रही है, तो कॉलआउट नीति से यह पता चलता है कि Edge को प्रोसेस करने में ज़्यादा समय लग रहा है अनुरोध.
7. यहां JavaScript नीति पर बहुत ज़्यादा बीत चुके समय को दिखाने वाला एक नमूना यूज़र इंटरफ़ेस (यूआई) ट्रेस दिया गया है:

   

8. ऊपर दिए गए उदाहरण में, आपने देखा है कि JavaScript नीति में ~ 245 सेकंड का समय है.

रिज़ॉल्यूशन

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

      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 स्टेटस कोड की संख्या किसी तय थ्रेशोल्ड से ज़्यादा होने पर, सूचना पाने की सुविधा सेट अप की जा सकती है.