Platform For AI：Lampiran: Panduan konfigurasi batas waktu timeout gateway khusus

Rekomendasi konfigurasi

Gateway khusus memiliki timeout koneksi idle tetap berikut, yang tidak dapat Anda ubah:

• Gateway sebagai server (menghadap klien): Tetap pada 600 detik. Gateway menutup koneksi antara klien dan gateway jika idle lebih lama dari periode ini.

• Gateway sebagai klien (menghadap layanan model): Tetap pada 30 detik. Gateway menutup koneksi antara gateway dan layanan model backend jika idle lebih lama dari periode ini.

Atur timeout koneksi idle klien menjadi nilai kurang dari timeout koneksi idle gateway khusus 600 detik. Praktik ini memastikan bahwa klien secara aktif mengelola dan menutup koneksi, yang mencegah kesalahan yang terjadi ketika klien mencoba menggunakan koneksi yang sudah ditutup oleh gateway.

Diagram berikut menggambarkan jalur koneksi:

Contoh konfigurasi klien

Contoh berikut menunjukkan cara mengelola atau menetapkan batas waktu koneksi idle klien dalam berbagai bahasa pemrograman.

import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.impl.conn.PoolingHttpClientConnectionManager;
import org.apache.http.client.config.RequestConfig;
import java.util.concurrent.TimeUnit;

public class HttpClientIdleTimeout {
    public static void main(String[] args) throws InterruptedException {
        PoolingHttpClientConnectionManager cm = new PoolingHttpClientConnectionManager();
        cm.setDefaultMaxPerRoute(20); // Nilai contoh: Koneksi maksimum per rute
        cm.setMaxTotal(100); // Nilai contoh: Total koneksi maksimum

        RequestConfig requestConfig = RequestConfig.custom()
                .setConnectTimeout(5000) // Nilai contoh: Batas waktu koneksi 5 detik
                .setSocketTimeout(10000) // Nilai contoh: Batas waktu membaca data 10 detik
                .build();

        try (CloseableHttpClient httpClient = HttpClients.custom()
                .setConnectionManager(cm)
                .setDefaultRequestConfig(requestConfig)
                .build()) {

            // Mulai thread backend untuk membersihkan koneksi idle secara berkala
            Thread cleanerThread = new Thread(() -> {
                try {
                    while (!Thread.currentThread().isInterrupted()) {
                        Thread.sleep(5000); // Nilai contoh: Periksa setiap 5 detik
                        // Tutup koneksi yang telah idle selama lebih dari 500 detik (kurang dari batas waktu idle gateway 600 detik)
                        cm.closeIdleConnections(500, TimeUnit.SECONDS);
                        // Tutup koneksi yang kedaluwarsa (misalnya, koneksi ditutup oleh server)
                        cm.closeExpiredConnections();
                    }
                } catch (InterruptedException e) {
                    Thread.currentThread().interrupt(); // Setel ulang status interupsi
                }
            });
            cleanerThread.setDaemon(true); // Setel sebagai thread daemon untuk keluar saat thread utama keluar
            cleanerThread.start();

            // Jalankan permintaan HTTP...
            // Contoh: httpClient.execute(new HttpGet("http://your-gateway-url"));

            // Simulasikan program berjalan selama beberapa saat
            Thread.sleep(60000); // Nilai contoh: Berjalan selama 1 menit

            // Hentikan thread pembersih (dalam aplikasi nyata, Anda harus menghentikannya dengan anggun saat aplikasi dimatikan)
            cleanerThread.interrupt();

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

package main

import (
    "net/http"
    "time"
)

func main() {
    // Buat Transport kustom
    tr := &http.Transport{
        MaxIdleConns:        100,              // Jumlah maksimum koneksi idle
        IdleConnTimeout:     500 * time.Second, // Timeout koneksi idle, misalnya, 500 detik (kurang dari 600 detik)
        DisableKeepAlives:   false,            // Aktifkan Keep-Alive
    }
}

import com.aliyun.openservices.eas.predict.http.PredictClient;
import com.aliyun.openservices.eas.predict.http.HttpConfig;

public class EasSdkTimeoutJava {
    public static void main(String[] args) {
        // 1. Konfigurasi client global
        HttpConfig httpConfig = new HttpConfig();
        // Aktifkan sakelar pembersihan koneksi idle, satuan: milidetik. Disarankan mengonfigurasi berdasarkan kondisi client.
        httpConfig.setConnectionCleanupInterval(5000);
        // Atur timeout koneksi idle agar kurang dari timeout idle gateway 600 detik
        httpConfig.setIdleConnectionTimeout(500);

        PredictClient client = new PredictClient(httpConfig);
        client.setEndpoint("your-eas-service-endpoint");
        client.setModelName("your-model-name");
        // client.setToken("your-token"); // Jika diperlukan autentikasi
        ...
    }
}

Rekomendasi konfigurasi

Anda dapat menyesuaikan request timeout berdasarkan kebutuhan bisnis Anda. Rekomendasi berikut hanya untuk referensi dan bukan aturan ketat. Di lingkungan produksi, Anda harus menyeimbangkan faktor-faktor seperti toleransi kesalahan, waktu respons, dan kemungkinan fluktuasi jaringan untuk menemukan pengaturan optimal untuk skenario bisnis Anda.

• Konfigurasi Timeout Permintaan Gateway Khusus: Atur timeout yang masuk akal berdasarkan logika bisnis dan waktu pemrosesan yang diharapkan dari layanan.

  • Nilai Default: 10 menit (600 detik).

  • Pengaturan yang Ditentukan Pengguna (tidak didukung saat ini oleh Application Load Balancer (ALB)-based dedicated gateways): Dalam file konfigurasi layanan, Anda dapat menyesuaikan timeout permintaan untuk layanan tertentu dengan menyetel bidang metadata.rpc.keepalive. Gateway membaca nilai ini dan menerapkannya sebagai timeout permintaan. Untuk informasi lebih lanjut, lihat deskripsi parameter metadata.

    Penting

    Koneksi jangka pendek dibatasi oleh timeout permintaan dan timeout koneksi idle. Karena timeout koneksi idle untuk gateway khusus tetap pada 600 detik, menyetel timeout permintaan lebih dari 600 detik tidak akan berpengaruh. Untuk tugas jangka panjang yang melebihi 10 menit, Anda dapat menggunakan salah satu solusi berikut:

    • Streaming: untuk skenario seperti unduhan file besar atau pembuatan konten AI.

    • WebSocket: untuk skenario komunikasi real-time dua arah.

• Konfigurasi Timeout Permintaan Klien: Untuk menghindari kesalahan timeout palsu yang terjadi ketika klien timeout sementara server masih memproses permintaan, Anda dapat menyetel timeout permintaan klien sedikit lebih lama daripada timeout permintaan server.

  • Rekomendasi umum adalah Client timeout = Server timeout + buffer kecil (misalnya, 1 hingga 5 detik).

  • Buffer memperhitungkan latensi jaringan kecil dan fluktuasi waktu pemrosesan di sisi server.

Diagram berikut menggambarkan jalur koneksi:

Contoh konfigurasi klien

Contoh berikut menunjukkan cara mengonfigurasi batas waktu permintaan sisi klien dalam berbagai bahasa pemrograman.

import org.apache.http.client.config.RequestConfig;
import org.apache.http.client.methods.CloseableHttpResponse;
import org.apache.http.client.methods.HttpGet;
import org.apache.http.impl.client.CloseableHttpClient;
import org.apache.http.impl.client.HttpClients;
import org.apache.http.util.EntityUtils;

public class ApacheHttpClientTimeout {
    public static void main(String[] args) {
        // Batas waktu permintaan klien yang direkomendasikan harus sedikit lebih besar dari atau sama dengan batas waktu permintaan gateway (600 detik secara default). Di sini, diatur ke 610 detik.
        RequestConfig requestConfig = RequestConfig.custom()
                .setConnectTimeout(5000) // Nilai contoh: Batas waktu koneksi, dalam milidetik
                .setSocketTimeout(610000) // Batas waktu transmisi data (read timeout), dalam milidetik (610 detik)
                .build();
    }
}

package main

import (
    "context"
    "fmt"
    "io"
    "net/http"
    "time"
)

func main() {
    // Batas waktu permintaan klien yang direkomendasikan harus sedikit lebih besar dari atau sama dengan batas waktu permintaan gateway (600 detik secara default). Di sini, diatur ke 610 detik.
    client := &http.Client{
        Timeout: 610 * time.Second, // Batas waktu untuk seluruh permintaan
    }

    req, err := http.NewRequest("GET", "http://your-gateway-url", nil)
    if err != nil {
        fmt.Println("Kesalahan membuat permintaan:", err)
        return
    }

    // Anda juga dapat menetapkan batas waktu yang lebih pendek untuk satu permintaan
    ctx, cancel := context.WithTimeout(req.Context(), 610*time.Second) // 610 detik
    defer cancel()
    req = req.WithContext(ctx)

    resp, err := client.Do(req)
    if err != nil {
            fmt.Println("Kesalahan mengirim permintaan:", err)
            // Periksa apakah itu kesalahan timeout
            if t, ok := err.(interface{ Timeout() bool }); ok && t.Timeout() {
                    fmt.Println("Permintaan timeout!")
            }
            return
    }
    defer resp.Body.Close()

    body, err := io.ReadAll(resp.Body)
    if err != nil {
        fmt.Println("Kesalahan membaca badan respons:", err)
        return
    }
    fmt.Printf("Status Respons: %s\n", resp.Status)
    fmt.Printf("Badan Respons: %s\n", body)
}

import com.aliyun.openservices.eas.predict.http.PredictClient;
import com.aliyun.openservices.eas.predict.http.HttpConfig;

public class EasSdkTimeoutJava {
    public static void main(String[] args) {
        // 1. Konfigurasi klien global
        HttpConfig httpConfig = new HttpConfig();
        // Batas waktu koneksi
        httpConfig.setConnectTimeout(5);
        // Batas waktu permintaan klien yang direkomendasikan harus sedikit lebih besar dari atau sama dengan batas waktu permintaan gateway (600 detik secara default). Di sini, diatur ke 610 detik.
        httpConfig.setReadTimeout(610); // Batas waktu baca
       
    }
}

T: Pengaturan timeout koneksi idle yang tidak tepat

Skenario 1: Timeout koneksi idle klien lebih besar dari timeout koneksi idle sisi server gateway khusus (client idle timeout > 600 detik)

• Masalah: Klien mengasumsikan bahwa koneksi masih valid, tetapi gateway khusus telah menutup koneksi karena tidak aktif. Ketika klien mencoba menggunakan kembali koneksi ini, permintaan gagal.

• Kesalahan Klien Umum:

  • Connection reset by peer

  • Broken pipe

  • java.net.SocketException: Connection reset (Java)

  • requests.exceptions.ConnectionError: ('Connection aborted.', ConnectionResetError(104, 'Connection reset by peer')) (Python requests)

  • read: connection reset by peer (Go)

  • Klien mungkin menerima kesalahan HTTP 503 Service Unavailable. Kesalahan ini biasanya terjadi ketika klien mencoba menggunakan kembali koneksi yang ditutup dan gateway tidak dapat membangun koneksi baru atau meneruskan permintaan ke layanan backend tepat waktu.

Skenario 2: Timeout koneksi idle sisi klien gateway khusus lebih besar dari timeout koneksi idle layanan model (model service idle timeout < 30 detik)

• Masalah: Gateway khusus mengasumsikan bahwa koneksi masih valid, tetapi layanan model backend telah menutup koneksi karena tidak aktif. Ketika gateway mencoba menggunakan kembali koneksi ini untuk meneruskan permintaan, ia menemukan bahwa koneksi rusak.

• Kesalahan Potensial Gateway Khusus: Log gateway menunjukkan kesalahan reset koneksi yang mirip dengan kesalahan klien yang dijelaskan di bagian sebelumnya.

• Kesalahan Klien Potensial: Klien biasanya menerima kode kesalahan HTTP 503 dari gateway khusus. Kesalahan ini menunjukkan bahwa gateway tidak dapat meneruskan permintaan ke layanan backend.

T: Pengaturan timeout permintaan yang tidak tepat

Skenario 1: Timeout permintaan klien lebih pendek dari timeout permintaan gateway khusus

• Masalah: Timeout permintaan yang dikonfigurasi klien terlalu singkat. Hal ini menyebabkan klien membatalkan koneksi sebelum menerima respons lengkap, yang mengakibatkan kesalahan timeout palsu yang sering mengganggu operasi bisnis.

  Penting

  Dalam beberapa skenario, klien mungkin secara sengaja menyetel timeout permintaan yang singkat untuk menerapkan strategi fail-fast. Oleh karena itu, nilai timeout yang direkomendasikan hanya untuk referensi dan dapat disesuaikan berdasarkan kebutuhan spesifik. Timeout klien tidak selalu harus lebih besar dari timeout sisi server. Saran ini berlaku untuk kasus penggunaan umum. Anda harus menyesuaikannya dengan konteks bisnis spesifik Anda.

• Kesalahan Klien Umum:

  Klien sering kali melempar pengecualian timeoutnya sendiri, seperti:

  • java.net.http.HttpTimeoutException (Java Http Client)

  • java.net.SocketTimeoutException: Read timed out (Java Apache HttpClient)

  • requests.exceptions.ReadTimeout (Python requests)

  • context deadline exceeded (Go, dipicu oleh context.WithTimeout atau Client.Timeout)

Skenario 2: Timeout permintaan gateway khusus lebih pendek dari waktu pemrosesan layanan model aktual

• Masalah: Timeout yang dikonfigurasi pada gateway khusus untuk meneruskan permintaan ke layanan model (default 10 menit atau nilai kustom) lebih pendek dari waktu yang sebenarnya dibutuhkan layanan model untuk memproses permintaan. Akibatnya, gateway berhenti menunggu sebelum layanan model selesai dan mengembalikan kesalahan timeout ke klien.

• Kesalahan Sisi Klien: Klien biasanya menerima kesalahan HTTP 504 Gateway Timeout dari gateway khusus. Kesalahan ini menunjukkan bahwa gateway timeout saat menunggu respons dari layanan backend. Klien mungkin juga menerima kesalahan HTTP 502 Bad Gateway atau HTTP 500 Internal Server Error, tergantung pada bagaimana layanan model menangani timeout internalnya dan melaporkan kesalahan ke gateway.

• Status Layanan Model: Layanan model mungkin masih memproses permintaan. Log layanan model tidak menunjukkan kesalahan timeout tetapi mungkin menunjukkan bahwa permintaan terputus jika gateway menutup koneksi ke layanan model setelah timeout.

• Rekomendasi Pemecahan Masalah: Untuk memecahkan masalah kesalahan ini, Anda dapat memeriksa log di klien, gateway, dan layanan model.

  • Periksa Log Klien: Tinjau jenis pengecualian spesifik dan jejak stack yang dilemparkan oleh klien.

  • Periksa Log Gateway Khusus: Periksa log permintaan gateway dan perhatikan khususnya kode kesalahan dan status penerusan yang terkait dengan permintaan yang gagal.

  • Periksa Log Layanan Model: Jika gateway mengembalikan kode kesalahan 5xx, Anda dapat memeriksa log layanan model untuk mengonfirmasi apakah terjadi kesalahan internal atau pemrosesan memakan waktu terlalu lama.