Sesi

Halaman ini menjelaskan konsep lanjutan sesi di Spanner, termasuk praktik terbaik untuk sesi saat membuat library klien, menggunakan REST API atau RPC API, atau menggunakan library klien Google.

Sesi menyediakan konteks untuk operasi database dengan layanan database Spanner. Sesi digunakan untuk menjalankan transaksi yang membaca, menulis, atau mengubah data dalam database Spanner. Setiap sesi berlaku untuk satu database.

Sesi dapat menjalankan satu atau beberapa transaksi sekaligus. Saat melakukan beberapa transaksi, sesi ini disebut sesi multipleks. Pembacaan, penulisan, dan kueri mandiri menggunakan satu transaksi secara internal.

Mengelola performa sesi

Sesi adalah konteks untuk operasi database, sehingga cara Anda mengelolanya akan langsung memengaruhi latensi dan penggunaan resource aplikasi Anda. Anda dapat mengelola performa sesi dengan tiga cara berikut:

• Menggunakan kumpulan sesi.
• Menggunakan sesi multipleks.
• Optimalkan konfigurasi saluran gRPC.

Menggunakan kumpulan sesi

Membuat sesi akan menambah latensi karena setiap sesi baru memerlukan perjalanan bolak-balik ke layanan database Spanner. Untuk mengurangi latensi ini, gunakan kumpulan sesi: kumpulan sesi yang tersedia dan siap digunakan. Daripada membuat sesi untuk setiap operasi, pool akan menampilkan sesi yang ada dan mengklaimnya kembali untuk digunakan kembali setelahnya. Hal ini menyebarkan latensi pembuatan sesi ke banyak operasi, bukan menghilangkannya sepenuhnya. Kumpulan ini menyimpan sesi yang ada, menampilkan jenis sesi yang sesuai saat diminta, dan membersihkan sesi yang tidak digunakan.

Sesi dimaksudkan untuk bertahan lama, jadi setelah sesi digunakan untuk operasi database, klien harus mengembalikan sesi ke kumpulan untuk digunakan kembali.

Menggunakan sesi multipleks

Sesi multipleks memungkinkan Anda membuat beberapa permintaan serentak dalam satu sesi, sehingga mengurangi overhead backend dan konsumsi resource. Untuk mengetahui informasi selengkapnya, lihat Sesi multipleks.

Mengoptimalkan konfigurasi saluran gRPC

Kurangi latensi tail yang tinggi (p95/p99) yang disebabkan oleh kepadatan saluran gRPC selama traffic tinggi dengan menyesuaikan kumpulan saluran gRPC. Di library klien yang didukung, penggabungan saluran dinamis secara otomatis mengubah ukuran gabungan saluran saat beban berubah. Hal ini membantu mengurangi latensi ekor yang terkait dengan kemacetan dan membantu menghindari penyediaan saluran yang kurang atau berlebihan.

Ringkasan saluran gRPC

Saluran gRPC digunakan oleh klien Spanner untuk komunikasi. Satu saluran gRPC kira-kira setara dengan koneksi TCP. Satu saluran gRPC dapat menangani hingga 100 permintaan serentak. Artinya, aplikasi akan memerlukan setidaknya saluran gRPC sebanyak jumlah permintaan serentak yang akan dijalankan aplikasi, dibagi 100.

Klien Spanner membuat kumpulan saluran gRPC saat Anda membuatnya.

Praktik terbaik saat menggunakan library klien Google

Berikut ini menjelaskan praktik terbaik saat menggunakan library klien Google untuk Spanner.

Mengonfigurasi jumlah sesi dan saluran gRPC di pool

Cara Anda mengelola sesi dan saluran gRPC bergantung pada library klien. Library klien yang mendukung sesi multipleks, seperti library klien Go dan Java, tidak mengharuskan Anda mengonfigurasi kumpulan sesi dan dapat mengelola kumpulan saluran gRPC untuk Anda melalui penggabungan saluran dinamis. Library klien lainnya menggunakan kumpulan sesi dengan jumlah sesi minimum dan maksimum default, serta jumlah saluran gRPC default. Nilai default sudah memadai untuk sebagian besar kasus. Bagian berikut menjelaskan opsi default dan konfigurasi untuk setiap bahasa pemrograman.

MinSessions: 100
MaxSessions: 400
NumChannels: 4

MinSessions: 100
MaxSessions: 400
NumChannels: 4

// Use 16 gRPC channels instead of the default of four.
client, err := spanner.NewClient(ctx,
    "projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    option.WithGRPCConnectionPool(16),
)

client, err := spanner.NewClientWithConfig(ctx,
    "projects/PROJECT_ID/instances/INSTANCE_ID/databases/DATABASE_ID",
    spanner.ClientConfig{
        DynamicChannelPoolConfig: spanner.DynamicChannelPoolConfig{
            DCPEnabled: true,
        },
    })

SpannerOptions options =
    SpannerOptions.newBuilder()
        .setProjectId("PROJECT_ID")
        .enableDynamicChannelPool()
        .build();

SpannerOptions options =
    SpannerOptions.newBuilder()
        .setProjectId("PROJECT_ID")
        .enableDynamicChannelPool()
        .setGcpChannelPoolOptions(
            GcpChannelPoolOptions.newBuilder()
                .setMaxSize(15)
                .setMinSize(3)
                .setInitSize(5)
                // setDynamicScaling(minRpcPerChannel, maxRpcPerChannel,
                // scaleDownInterval): scale up as soon as a channel's load
                // exceeds 30 concurrent RPCs. Scale-up is event-driven, so
                // the pool grows immediately as load rises. Scale-down is
                // periodic: a channel is removed only after it stays under
                // 10 concurrent RPCs across the check that runs every 5
                // minutes.
                .setDynamicScaling(10, 30, Duration.ofMinutes(5))
                .build())
        .build();

MinSessions: 25
MaxSessions: 100

MaxChannels: 10
ConcurrentRequestsPerChannel: 25

const {Spanner} = require('@google-cloud/spanner');
    // Note: Ensure grpcGcp is initialized
const customGcpApiConfig = {
  channelPool: {
    maxSize: 20, // Overriding default 10
    maxConcurrentStreamsLowWatermark: 50 // Overriding default 25
  }
};
const spanner = new Spanner({
  'grpc.gcpApiConfig': grpcGcp.createGcpApiConfig(customGcpApiConfig)
});

MinSessions: 1
MaxSessions: 500

MinSessions: 10
MaxSessions: 100

Gunakan sesi multipleks jika library klien untuk bahasa pemrograman Anda mendukungnya. Sesi multipleks tidak memerlukan konfigurasi apa pun, dan satu sesi multipleks dapat menjalankan sejumlah transaksi serentak.

Jumlah sesi yang digunakan aplikasi Anda sama dengan jumlah transaksi serentak yang dijalankan aplikasi Anda. Anda hanya boleh mengubah setelan kumpulan sesi default jika Anda memperkirakan satu instance aplikasi akan menjalankan lebih banyak transaksi serentak daripada yang dapat ditangani oleh kumpulan sesi default.

Untuk aplikasi konkurensi tinggi, sebaiknya lakukan hal berikut:

1. Tetapkan MinSessions ke jumlah transaksi serentak yang diharapkan yang akan dijalankan oleh satu klien.
2. Tetapkan MaxSessions ke jumlah maksimum transaksi serentak yang dapat dijalankan oleh satu klien.
3. Tetapkan MinSessions=MaxSessions jika konkurensi yang diharapkan tidak banyak berubah selama masa aktif aplikasi. Tindakan ini mencegah penskalaan naik atau turun pada kumpulan sesi. Peningkatan atau penurunan skala kumpulan sesi juga menggunakan beberapa resource.
4. Tetapkan NumChannels ke MaxSessions / 100. Satu saluran gRPC dapat menangani hingga 100 permintaan secara serentak. Tingkatkan nilai ini jika Anda mengamati latensi tail yang tinggi (latensi p95/p99), karena ini dapat menjadi indikasi kemacetan saluran gRPC.

Meningkatkan jumlah sesi aktif akan menggunakan resource tambahan di layanan database Spanner dan di library klien. Meningkatkan jumlah sesi melebihi kebutuhan aplikasi yang sebenarnya dapat menurunkan performa sistem Anda.

Meningkatkan kumpulan sesi versus meningkatkan jumlah klien

Ukuran kumpulan sesi untuk aplikasi menentukan jumlah transaksi serentak yang dapat dijalankan oleh satu instance aplikasi. Meningkatkan ukuran kumpulan sesi melebihi konkurensi maksimum yang dapat ditangani oleh satu instance aplikasi tidak direkomendasikan. Jika aplikasi menerima lonjakan permintaan yang melebihi jumlah sesi dalam kumpulan, permintaan akan diantrekan sambil menunggu sesi tersedia.

Resource yang digunakan oleh library klien adalah sebagai berikut:

1. Setiap saluran gRPC menggunakan satu koneksi TCP.
2. Setiap pemanggilan gRPC memerlukan thread. Jumlah maksimum thread yang digunakan oleh library klien sama dengan jumlah maksimum kueri serentak yang dijalankan aplikasi. Thread ini berada di atas thread apa pun yang digunakan aplikasi untuk logika bisnisnya sendiri.

Sebaiknya jangan meningkatkan ukuran kumpulan sesi melebihi jumlah maksimum thread yang dapat ditangani oleh satu instance aplikasi. Sebagai gantinya, tingkatkan jumlah instance aplikasi.

Mengelola pecahan sesi tulis

Untuk beberapa library klien, Spanner mencadangkan sebagian sesi untuk transaksi baca-tulis, yang disebut pecahan sesi tulis. Jika aplikasi Anda menghabiskan semua sesi baca, Spanner akan menggunakan sesi baca-tulis, bahkan untuk transaksi hanya baca. Sesi baca-tulis memerlukan spanner.databases.beginOrRollbackReadWriteTransaction. Jika pengguna berada dalam peran IAM spanner.databaseReader, panggilan akan gagal dan Spanner akan menampilkan pesan error ini:

generic::permission_denied: Resource %resource% is missing IAM permission:
spanner.databases.beginOrRollbackReadWriteTransaction

Untuk library klien yang mempertahankan pecahan sesi tulis, Anda dapat menetapkan pecahan sesi tulis.

Praktik terbaik saat membuat library klien atau menggunakan REST/RPC

Berikut ini adalah praktik terbaik untuk mengimplementasikan sesi di library klien untuk Spanner, atau untuk menggunakan sesi dengan API REST atau RPC.

Praktik terbaik ini hanya berlaku jika Anda mengembangkan library klien, atau jika Anda menggunakan REST/RPC API. Jika Anda menggunakan salah satu library klien Google untuk Spanner, lihat Praktik terbaik saat menggunakan library klien Google.

Membuat dan menentukan ukuran kumpulan sesi

Untuk menentukan ukuran optimal kumpulan sesi untuk proses klien, tetapkan batas bawah ke jumlah transaksi serentak yang diharapkan, dan tetapkan batas atas ke jumlah pengujian awal, seperti 100. Jika batas atas tidak memadai, tingkatkan. Meningkatkan jumlah sesi aktif akan menggunakan resource tambahan pada layanan database Spanner, sehingga kegagalan dalam membersihkan sesi yang tidak digunakan dapat menurunkan performa. Untuk pengguna yang menggunakan RPC API, sebaiknya miliki tidak lebih dari 100 sesi per saluran gRPC.

Menangani sesi yang dihapus

Ada tiga cara untuk menghapus sesi:

• Klien dapat menghapus sesi.
• Layanan database Spanner dapat menghapus sesi jika sesi tidak aktif selama lebih dari 1 jam.
• Layanan database Spanner dapat menghapus sesi jika sesi tersebut berusia lebih dari 28 hari.

Upaya untuk menggunakan sesi yang dihapus akan menghasilkan NOT_FOUND. Jika Anda mengalami error ini, buat dan gunakan sesi baru, tambahkan sesi baru ke pool, dan hapus sesi yang dihapus dari pool.

Mempertahankan sesi tidak ada aktivitas agar tetap aktif

Layanan database Spanner berhak menghapus sesi yang tidak digunakan. Jika Anda benar-benar perlu menjaga sesi nonaktif tetap aktif, misalnya, jika diperkirakan akan ada peningkatan penggunaan database yang signifikan dalam waktu dekat, Anda dapat mencegah sesi tersebut dihentikan. Lakukan operasi yang murah seperti menjalankan kueri SQL SELECT 1 agar sesi tetap aktif. Jika Anda memiliki sesi tidak ada aktivitas yang tidak diperlukan untuk penggunaan dalam waktu dekat, biarkan Spanner menghapus sesi tersebut, lalu buat sesi baru saat sesi diperlukan lagi.

Salah satu skenario untuk menjaga sesi tetap aktif adalah menangani permintaan puncak reguler pada database. Jika penggunaan database yang berat terjadi setiap hari dari pukul 09.00 hingga 18.00, Anda harus menjaga beberapa sesi nonaktif tetap aktif selama waktu tersebut, karena sesi tersebut kemungkinan diperlukan untuk penggunaan puncak. Setelah pukul 18.00, Anda dapat mengizinkan Spanner menghapus sesi tidak ada aktivitas. Sebelum pukul 09.00 setiap hari, buat beberapa sesi baru agar siap untuk permintaan yang diharapkan.

Skenario lainnya adalah jika Anda memiliki aplikasi yang menggunakan Spanner, tetapi harus menghindari overhead koneksi saat melakukannya. Anda dapat mempertahankan sekumpulan sesi agar tetap aktif untuk menghindari overhead koneksi.

Menyembunyikan detail sesi dari pengguna library klien

Jika Anda membuat library klien, jangan ekspos sesi ke konsumen library klien. Memberikan kemampuan kepada klien untuk melakukan panggilan database tanpa kerumitan dalam membuat dan mengelola sesi. Untuk contoh library klien yang menyembunyikan detail sesi dari konsumen library klien, lihat library klien Spanner untuk Java.

Menangani error untuk transaksi tulis yang tidak idempoten

Transaksi tulis tanpa perlindungan replay dapat menerapkan mutasi lebih dari sekali. Jika mutasi tidak idempoten, mutasi yang diterapkan lebih dari sekali dapat mengakibatkan kegagalan. Misalnya, penyisipan mungkin gagal dengan ALREADY_EXISTS meskipun baris tidak ada sebelum upaya penulisan. Hal ini dapat terjadi jika server backend melakukan mutasi, tetapi tidak dapat mengomunikasikan keberhasilan tersebut kepada klien. Dalam peristiwa tersebut, mutasi dapat dicoba lagi, sehingga menghasilkan kegagalan ALREADY_EXISTS.

Berikut adalah kemungkinan cara untuk mengatasi skenario ini saat Anda menerapkan library klien Anda sendiri atau menggunakan REST API:

• Susun penulisan Anda agar idempoten.
• Gunakan penulisan dengan perlindungan replay.
• Terapkan metode yang menjalankan logika "upsert": sisipkan jika baru atau update jika ada.
• Menangani error atas nama klien.

Mempertahankan koneksi yang stabil

Untuk mendapatkan performa terbaik, koneksi yang Anda gunakan untuk menghosting sesi harus tetap stabil. Saat koneksi yang menghosting sesi berubah, Spanner mungkin akan membatalkan transaksi aktif pada sesi tersebut dan menyebabkan sedikit beban tambahan pada database Anda saat mengupdate metadata sesi. Tidak masalah jika beberapa koneksi berubah secara sporadis, tetapi Anda harus menghindari situasi yang akan mengubah sejumlah besar koneksi secara bersamaan. Jika Anda menggunakan proxy antara klien dan Spanner, Anda harus menjaga stabilitas koneksi untuk setiap sesi.

Memantau sesi aktif

Anda dapat menggunakan perintah ListSessions untuk memantau sesi aktif di database Anda dari command line, dengan REST API, atau dengan RPC API. ListSessions menampilkan sesi aktif untuk database tertentu. Hal ini berguna jika Anda perlu menemukan penyebab kebocoran sesi. (Kebocoran sesi adalah insiden saat sesi dibuat, tetapi tidak dikembalikan ke kumpulan sesi untuk digunakan kembali.)

ListSessions memungkinkan Anda melihat metadata tentang sesi aktif, termasuk kapan sesi dibuat dan kapan sesi terakhir digunakan. Menganalisis data ini akan mengarahkan Anda ke arah yang benar saat memecahkan masalah sesi. Jika sebagian besar sesi aktif tidak memiliki approximate_last_use_time terbaru, hal ini dapat mengindikasikan bahwa sesi tidak digunakan kembali dengan benar oleh aplikasi Anda. Lihat referensi RPC API untuk mengetahui informasi selengkapnya tentang kolom approximate_last_use_time.

Lihat referensi REST API, referensi RPC API, atau referensi alat command line gcloud untuk mengetahui informasi selengkapnya tentang cara menggunakan ListSessions.

Pembersihan otomatis kebocoran sesi

Saat Anda menggunakan semua sesi di kumpulan sesi, setiap transaksi baru akan menunggu hingga sesi dikembalikan ke kumpulan. Jika sesi dibuat, tetapi tidak ditampilkan ke kumpulan sesi untuk digunakan kembali, hal ini disebut kebocoran sesi. Jika terjadi kebocoran sesi, transaksi yang menunggu sesi terbuka akan macet tanpa batas waktu dan memblokir aplikasi. Kebocoran sesi sering kali disebabkan oleh transaksi bermasalah yang berjalan dalam waktu yang sangat lama dan tidak di-commit.

Anda dapat menyiapkan kumpulan sesi untuk otomatis menyelesaikan transaksi yang tidak aktif ini. Saat Anda mengaktifkan library klien untuk otomatis menyelesaikan transisi tidak aktif, library ini akan mengidentifikasi transaksi bermasalah yang mungkin menyebabkan kebocoran sesi, menghapusnya dari kumpulan sesi, dan menggantinya dengan sesi baru.

Logging juga dapat membantu mengidentifikasi transaksi yang bermasalah ini. Jika logging diaktifkan, log peringatan akan dibagikan secara default saat lebih dari 95% kumpulan sesi Anda sedang digunakan. Jika penggunaan sesi Anda lebih besar dari 95%, Anda perlu meningkatkan sesi maksimum yang diizinkan di kumpulan sesi, atau mungkin ada kebocoran sesi. Log peringatan berisi stack trace transaksi yang berjalan lebih lama dari yang diperkirakan dan dapat membantu mengidentifikasi penyebab pemakaian kumpulan sesi yang tinggi. Log peringatan dikirim bergantung pada konfigurasi pengekspor log Anda.

Mengaktifkan library klien untuk otomatis menyelesaikan transaksi yang tidak aktif

Anda dapat mengaktifkan library klien untuk mengirim log peringatan dan otomatis menyelesaikan transaksi yang tidak aktif, atau mengaktifkan library klien untuk hanya menerima log peringatan.

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnAndCloseIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

 final SessionPoolOptions sessionPoolOptions = SessionPoolOptions.newBuilder().setWarnIfInactiveTransactions().build()

 final Spanner spanner =
         SpannerOptions.newBuilder()
             .setSessionPoolOption(sessionPoolOptions)
             .build()
             .getService();
 final DatabaseClient client = spanner.getDatabaseClient(databaseId);

 client, err := spanner.NewClientWithConfig(
     ctx, database, spanner.ClientConfig{SessionPoolConfig: spanner.SessionPoolConfig{
         InactiveTransactionRemovalOptions: spanner.InactiveTransactionRemovalOptions{
         ActionOnInactiveTransaction: spanner.WarnAndClose,
         }
     }},
 )
 if err != nil {
     return err
 }
 defer client.Close()

 customLogger := log.New(os.Stdout, "spanner-client: ", log.Lshortfile)
 // Create a logger instance using the golang log package
 cfg := spanner.ClientConfig{
         Logger: customLogger,
     }
 client, err := spanner.NewClientWithConfig(ctx, db, cfg)

Sesi multipleks

Sesi multipleks memungkinkan Anda membuat sejumlah besar permintaan serentak pada satu sesi. Sesi multipleks adalah ID yang Anda gunakan di beberapa saluran gRPC. Hal ini tidak menimbulkan bottleneck tambahan. Sesi multipleks memiliki keunggulan berikut:

• Pengurangan konsumsi resource backend karena protokol pengelolaan sesi yang lebih sederhana. Misalnya, mereka menghindari aktivitas pemeliharaan sesi yang terkait dengan pemeliharaan kepemilikan sesi dan pembersihan sampah memori.
• Sesi berdurasi panjang yang tidak memerlukan permintaan keep-alive saat tidak ada aktivitas.

Sesi multipleks didukung dalam hal berikut:

• Library klien C++, Go, Java, Node.js, PHP, Python, Ruby, dan Rust.

• Alat ekosistem Spanner yang bergantung pada Library klien yang disebutkan, seperti PGAdapter, JDBC, Hibernate, driver database/sql, driver dbAPI, dan GORM.

• Alat ekosistem Spanner yang bergantung pada Library klien Java dan Go, seperti PGAdapter, JDBC, Hibernate, database atau driver sql, dan GORM. Anda dapat menggunakan metrik OpenTelemetry untuk melihat cara traffic dibagi antara kumpulan sesi yang ada dan sesi multipleks. OpenTelemetry memiliki filter metrik, is_multiplexed, yang menampilkan sesi multipleks jika ditetapkan ke true.

Sesi multipleks didukung untuk semua jenis transaksi.

Library klien merotasi sesi multipleks setiap 7 hari untuk mencegah pengiriman transaksi pada sesi yang sudah tidak berlaku.

Sesi multipleks diaktifkan secara default di beberapa library klien. Untuk fitur lainnya, Anda harus menggunakan variabel lingkungan untuk mengaktifkannya. Untuk mengetahui detailnya, lihat Mengaktifkan sesi multipleks.

Pertimbangan

Jika Anda mencoba meng-commit isi transaksi baca atau tulis yang kosong atau transaksi yang setiap kueri atau pernyataan DML-nya gagal, ada beberapa skenario yang perlu dipertimbangkan dengan sesi multipleks. Sesi multipleks mengharuskan Anda menyertakan token pra-commit yang dihasilkan server di setiap permintaan commit. Untuk transaksi yang berisi kueri atau DML, harus ada setidaknya satu transaksi kueri atau DML yang berhasil sebelumnya agar server dapat mengirim kembali token yang valid ke library klien. Jika belum ada kueri atau transaksi DML yang berhasil, library klien akan menambahkan SELECT 1 secara implisit sebelum commit.

Untuk transaksi baca atau tulis pada sesi multipleks yang hanya memiliki mutasi, jika salah satu mutasi ditujukan untuk tabel atau kolom yang TIDAK ada dalam skema, klien dapat menampilkan error INVALID_ARGUMENT, bukan error NOT_FOUND.

Mengaktifkan sesi multipleks

Sesi multipleks diaktifkan secara default di library klien berikut:

• C++ di versi 2.41.0 dan yang lebih baru.
• Go di versi 1.85.0 dan yang lebih baru.
• Java di versi 6.98.0 dan yang lebih baru.
• Node.js di versi 8.3.0 dan yang lebih baru.
• PHP dalam versi 2.0.0 dan yang lebih baru.
• Python di versi 3.57.0 dan yang lebih baru.
• Ruby di versi 2.30.0 dan yang lebih baru.

Untuk menggunakan sesi multipleks di library klien Node.js, Java, dan Go versi sebelumnya, Anda harus menetapkan variabel lingkungan terlebih dahulu untuk mengaktifkannya.

Untuk mengaktifkan sesi multipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS ke TRUE. Flag ini juga mengaktifkan dukungan sesi multipleks untuk transaksi ReadOnly.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS=TRUE

Untuk mengaktifkan dukungan operasi yang dipartisi untuk sesi multipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS ke TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_PARTITIONED_OPS=TRUE

Untuk mengaktifkan dukungan transaksi baca-tulis untuk sesi multipleks, tetapkan variabel lingkungan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW ke TRUE.

export GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS_FOR_RW=True

Anda harus menetapkan GOOGLE_CLOUD_SPANNER_MULTIPLEXED_SESSIONS ke TRUE sebagai prasyarat untuk mendukung transaksi pada sesi multipleks.

Melihat traffic untuk sesi reguler dan multipleks

OpenTelemetry menyertakan filter is_multiplexed untuk menampilkan traffic untuk sesi multipleks. Tetapkan filter ini ke true untuk melihat sesi multipleks atau false untuk melihat sesi reguler.

1. Siapkan OpenTelemetry untuk Spanner menggunakan prosedur di bagian Sebelum memulai OpenTelemetry Spanner.

2. Buka Metrics Explorer.

   Buka Metrics Explorer

3. Di drop-down Metric, filter pada generic.

4. Klik Generic Task, lalu buka Spanner > Spanner/num_acquired_sessions.

5. Di kolom Filter, pilih salah satu opsi berikut:

   a. is_multiplexed = false untuk melihat sesi reguler. b. is_multiplexed = true untuk melihat sesi multipleks.

   Gambar berikut menampilkan opsi Filter dengan sesi multipleks yang dipilih.

Untuk mengetahui informasi selengkapnya tentang penggunaan OpenTelemetry dengan Spanner, lihat Memanfaatkan OpenTelemetry untuk mendemokratisasi Kemampuan Observasi Spanner dan Memeriksa latensi dalam komponen Spanner dengan OpenTelemetry.

Memecahkan masalah

Error umum terkait sesi yang mungkin dialami aplikasi Anda meliputi:

• Session not found
• RESOURCE_EXHAUSTED

Untuk mengetahui informasi selengkapnya, lihat Error sesi.