ID region
REGION_ID
adalah kode singkat yang ditetapkan Google berdasarkan region yang Anda pilih saat membuat aplikasi. Kode ini tidak sesuai dengan negara atau provinsi, meskipun beberapa ID region mungkin tampak mirip dengan kode negara dan provinsi yang umum digunakan. Untuk aplikasi yang dibuat setelah Februari 2020, REGION_ID.r
disertakan dalam URL App Engine. Untuk aplikasi lama yang dibuat sebelum tanggal tersebut, ID region bersifat opsional dalam URL.
Pelajari ID region lebih lanjut.
Dokumen ini menjelaskan cara aplikasi App Engine Anda menerima permintaan dan mengirim respons.
Untuk mengetahui detail selengkapnya, lihat Referensi Header dan Respons Permintaan.
Jika aplikasi Anda menggunakan layanan, Anda dapat mengajukan permintaan ke layanan tertentu atau versi tertentu dari layanan tersebut. Untuk mengetahui informasi selengkapnya tentang cara respons layanan, lihat Cara Permintaan Dirutekan.
Menangani permintaan
Aplikasi Anda bertanggung jawab memulai server web dan menangani permintaan. Anda dapat menggunakan framework web apa pun yang tersedia untuk bahasa pengembangan Anda.
App Engine menjalankan beberapa instance aplikasi Anda, dan setiap instance memiliki server web sendiri untuk menangani permintaan. Setiap permintaan dapat dirutekan ke instance mana saja, sehingga permintaan berturut-turut dari pengguna yang sama belum tentu
dikirim ke instance yang sama. Satu instance dapat menangani beberapa permintaan secara serentak. Jumlah instance dapat disesuaikan secara otomatis saat traffic berubah.
Anda juga dapat mengubah jumlah permintaan serentak yang dapat ditangani instance
dengan menyetel elemen max_concurrent_requests
di file app.yaml Anda.
Server menentukan skrip pengendali PHP yang akan dijalankan dengan membandingkan URL permintaan dengan pola URL di file konfigurasi app.yaml
aplikasi. Kemudian, skrip yang berisi data permintaan akan dijalankan. Server
menempatkan data permintaan dalam variabel lingkungan dan aliran data
input standar. Skrip melakukan tindakan yang sesuai dengan permintaan, lalu menyiapkan
respons dan menempatkannya di aliran data output standar.
Contoh berikut adalah skrip PHP yang merespons permintaan HTTP apa pun dengan pesan 'Hello World!'
Kuota dan batas
App Engine otomatis mengalokasikan resource ke aplikasi Anda saat traffic meningkat. Namun, ini terikat oleh pembatasan berikut:
App Engine mencadangkan kapasitas penskalaan otomatis untuk aplikasi dengan latensi rendah, saat aplikasi merespons permintaan dalam waktu kurang dari satu detik.
Aplikasi yang sangat terikat dengan CPU juga dapat menimbulkan beberapa latensi tambahan untuk berbagi resource secara efisien dengan aplikasi lain di server yang sama. Permintaan untuk file statis dikecualikan dari batas latensi ini.
Setiap permintaan yang masuk ke aplikasi akan dihitung dalam batas Permintaan. Data yang dikirim sebagai respons terhadap permintaan akan dihitung dalam batas Bandwidth Keluar (dapat ditagih).
Permintaan HTTP dan HTTPS (aman) diperhitungkan dalam batas Permintaan, Bandwidth Masuk (dapat ditagih), dan Bandwidth Keluar (dapat ditagih). Halaman Detail Kuota konsol Google Cloud juga melaporkan Permintaan Aman, Bandwidth Masuk Aman, dan Bandwidth Keluar Aman sebagai nilai terpisah untuk tujuan informasi. Hanya permintaan HTTPS yang diperhitungkan dalam nilai ini. Untuk mengetahui informasi selengkapnya, lihat halaman Kuota.
Batas berikut berlaku khusus untuk penggunaan pengendali permintaan:
Batas | Jumlah |
---|---|
Ukuran permintaan | 32 megabyte |
Ukuran respons | 32 megabyte |
Waktu tunggu permintaan | Tergantung jenis penskalaan yang digunakan aplikasi Anda |
Jumlah total maksimum file (file aplikasi dan file statis) | Total 10.000 1.000 per direktori |
Ukuran maksimum file aplikasi | 32 megabyte |
Ukuran maksimum file statis | 32 megabyte |
Ukuran total maksimum untuk semua file aplikasi dan file statis | Gratis 1 gigabyte pertama $ 0,026 per gigabyte per bulan setelah 1 gigabyte pertama |
Waktu tunggu permintaan tertunda | 10 detik |
Ukuran maksimum satu kolom header permintaan | 8 kilobyte untuk runtime generasi kedua di lingkungan standar. Permintaan ke runtime ini dengan kolom header yang melebihi 8 kilobyte akan menampilkan error HTTP 400. |
Batas permintaan
Semua permintaan HTTP/2 akan diterjemahkan menjadi permintaan HTTP/1.1 saat diteruskan ke server aplikasi.
Batas respons
Respons dinamis dibatasi hingga 32 MB. Jika pengendali skrip menghasilkan respons yang lebih besar dari batas ini, server akan mengirim kembali respons kosong dengan kode status Error Server Internal 500. Batasan ini tidak berlaku untuk respons yang menyalurkan data dari Cloud Storage.
Batas header respons adalah 8 KB untuk runtime generasi kedua. Header respons yang melebihi batas ini akan menampilkan error HTTP 502, dengan log yang menampilkan
upstream sent too big header while reading response header from upstream
.
Header permintaan
Permintaan HTTP masuk menyertakan header HTTP yang dikirim oleh klien. Untuk tujuan keamanan, beberapa header dibersihkan atau diubah oleh proxy perantara sebelum mencapai aplikasi.
Untuk mengetahui informasi selengkapnya, lihat Referensi header permintaan.
Menangani waktu tunggu permintaan
App Engine dioptimalkan untuk aplikasi dengan permintaan berumur pendek, biasanya yang memerlukan waktu beberapa ratus milidetik. Aplikasi yang efisien akan merespons sebagian besar permintaan dengan cepat. Aplikasi yang tidak diskalakan dengan baik dengan infrastruktur App Engine. Untuk memastikan tingkat performa ini, ada waktu tunggu permintaan maksimum yang diberlakukan oleh sistem yang harus direspons oleh setiap aplikasi.
Jika skrip PHP melebihi batas waktu ini, bitTIMEOUT
pada bitfield status koneksi akan ditetapkan. Skrip Anda kemudian akan memiliki batas waktu kedua yang singkat untuk membersihkan tugas yang berjalan lama dan menampilkan respons kepada pengguna.
Jika skrip belum menampilkan respons hingga batas waktu kedua, pengendali akan dihentikan dan respons error default akan ditampilkan.
Respons
App Engine memanggil skrip dengan array$_REQUEST
yang terisi,
melakukan buffering pada output apa pun dari skrip, dan saat skrip menyelesaikan eksekusi,
akan mengirimkan output yang di-buffer ke pengguna akhir.
Ada batas ukuran yang berlaku untuk respons yang Anda buat, dan respons dapat diubah sebelum ditampilkan ke klien.
Untuk informasi selengkapnya, lihat Referensi respons permintaan.Respons Streaming
App Engine tidak mendukung respons streaming ketika data dikirim dalam potongan inkremental ke klien saat permintaan sedang diproses. Semua data dari kode Anda dikumpulkan seperti yang dijelaskan di atas dan dikirim sebagai respons HTTP tunggal.
Kompresi respons
App Engine melakukan yang terbaik untuk menayangkan konten terkompresi (gzip) kepada klien yang mendukungnya. Untuk menentukan apakah konten harus dikompresi, App Engine melakukan hal berikut saat menerima permintaan:Mengonfirmasi apakah klien dapat menerima respons terkompresi secara andal dengan melihat header
Accept-Encoding
danUser-Agent
dalam permintaan. Pendekatan ini menghindari beberapa bug umum dengan konten yang dikompresi dengan gzip di browser populer.Konfirmasi apakah kompresi konten sudah sesuai dengan melihat header
Content-Type
yang telah Anda konfigurasi untuk pengendali respons. Secara umum, kompresi sesuai untuk jenis konten berbasis teks, bukan jenis konten biner.
Perhatikan hal-hal berikut:
Klien dapat memaksa jenis konten berbasis teks dikompresi dengan menetapkan header permintaan
Accept-Encoding
danUser-Agent
kegzip
.Jika permintaan tidak menentukan
gzip
pada headerAccept-Encoding
, App Engine tidak akan mengompresi data respons.Google Frontend menyimpan respons dari file statis App Engine dan pengendali direktori ke dalam cache. Bergantung pada berbagai faktor, seperti jenis data respons yang disimpan dalam cache terlebih dahulu, header
Vary
mana yang telah Anda tentukan dalam respons, dan header mana yang disertakan dalam permintaan, klien dapat meminta data yang dikompresi tetapi menerima data yang tidak dikompresi, begitu juga sebaliknya. Untuk mengetahui informasi selengkapnya, lihat Penyimpanan respons dalam cache.
Penyimpanan dalam cache respons
Google Frontend, dan kemungkinan browser yang digunakan pengguna serta server proxy dengan cache perantara lainnya, akan menyimpan dalam cache respons aplikasi Anda seperti yang diinstruksikan oleh header penyimpanan cache standar yang Anda tentukan dalam respons. Anda dapat menentukan header respons ini melalui framework, langsung di kode, atau melalui pengendali direktori dan file statis App Engine.
Di Google Frontend, kunci cache adalah URL lengkap permintaan.
Menyimpan konten statis ke dalam cache
Untuk memastikan bahwa klien selalu menerima konten statis yang diperbarui segera setelah
dipublikasikan, sebaiknya Anda menayangkan konten statis dari direktori
berversi, seperti css/v1/styles.css
. Google Frontend tidak akan memvalidasi
cache (memeriksa konten yang diperbarui) hingga cache berakhir. Bahkan setelah
masa berlaku cache berakhir, cache tidak akan diperbarui hingga konten di URL
permintaan berubah.
Header respons berikut yang dapat Anda
tetapkan di
app.yaml
memengaruhi cara dan waktu Google Frontend menyimpan konten dalam cache:
Cache-Control
harus disetel kepublic
agar Google Frontend dapat menyimpan konten dalam cache; tetapi juga dapat disimpan dalam cache oleh Google Frontend, kecuali jika Anda menentukan perintahCache-Control
private
atauno-store
. Jika Anda tidak menetapkan header ini diapp.yaml
, App Engine akan otomatis menambahkannya untuk semua respons yang ditangani oleh file statis atau pengendali direktori. Untuk mengetahui informasi selengkapnya, lihat Header yang ditambahkan atau diganti.Vary
: Agar cache dapat menampilkan respons yang berbeda untuk URL berdasarkan header yang dikirim dalam permintaan, tentukan satu atau beberapa nilai berikut di header respondsVary
:Accept
danAccept-Encoding
danOrigin
, atauX-Origin
Karena potensi kardinalitas yang tinggi, data untuk
Vary
lainnya tidak akan disimpan dalam cache.Contoh:
Anda menentukan header respons berikut:
Vary: Accept-Encoding
Aplikasi Anda menerima permintaan yang berisi header
Accept-Encoding: gzip
. App Engine menampilkan respons terkompresi dan Google Frontend meng-cache versi data respons yang di-gzip. Semua permintaan berikutnya untuk URL ini yang berisi headerAccept-Encoding: gzip
akan menerima data hasil gzip dari cache hingga cache menjadi tidak valid (karena konten berubah setelah cache berakhir masa berlakunya).Aplikasi Anda akan menerima permintaan yang tidak berisi header
Accept-Encoding
. App Engine menampilkan respons yang tidak dikompresi dan Google Frontend akan meng-cache versi data respons yang tidak dikompresi. Semua permintaan berikutnya untuk URL ini yang tidak berisi headerAccept-Encoding
akan menerima data terkompresi dari cache hingga cache menjadi tidak valid.
Jika Anda tidak menentukan header respons
Vary
, Google Frontend akan membuat satu entri cache untuk URL dan akan menggunakannya untuk semua permintaan, terlepas dari header dalam permintaan. Contoh:- Anda tidak menentukan header respons
Vary: Accept-Encoding
. - Permintaan berisi header
Accept-Encoding: gzip
, dan versi data respons yang di-gzip akan disimpan dalam cache. - Permintaan kedua tidak berisi header
Accept-Encoding: gzip
. Namun, karena cache berisi versi data respons yang di-gzip, respons akan di-gzip meskipun klien meminta data yang tidak dikompresi.
Header dalam permintaan juga memengaruhi penyimpanan cache:
- Jika permintaan berisi header
Authorization
, konten tidak akan disimpan dalam cache oleh Google Frontend.
Masa berlaku cache
Secara default, header caching yang ditambahkan oleh file statis dan pengendali direktori App Engine ke respons memerintahkan klien dan proxy web seperti Google Frontend untuk menghentikan masa berlaku cache setelah 10 menit.
Setelah file dikirimkan dengan waktu habis masa berlaku tertentu, biasanya tidak mungkin untuk menghapusnya dari cache web-proxy, meskipun pengguna menghapus cache browsernya sendiri. Men-deploy ulang versi baru aplikasi tidak akan mereset cache apa pun. Oleh karena itu, jika Anda berencana mengubah file statis, file tersebut harus memiliki waktu habis masa berlaku yang singkat (kurang dari satu jam). Biasanya, waktu habis masa berlaku default 10 menit sudah sesuai.
Anda dapat mengubah masa penyimpanan default untuk semua file statis dan pengendali direktori dengan menentukan elemen
default_expiration
pada file
app.yaml
Anda. Untuk menetapkan masa penyimpanan yang spesifik untuk masing-masing pengendali, tentukan elemen expiration
dalam elemen pengendali di file
app.yaml
Anda.
Nilai yang Anda tentukan dalam waktu masa penyimpanan elemen akan digunakan untuk menetapkan header respons HTTP Cache-Control
dan Expires
.
Penyimpanan aplikasi dalam cache
Lingkungan runtime PHP mencakup OPcache yang dapat menyimpan kode perantara PHP dalam cache dan meningkatkan waktu respons aplikasi Anda secara signifikan. Anda dapat menonaktifkan cache OPcache dengan menyetelopcache.enabled = "0"
di file php.ini aplikasi.
Logging
Server web App Engine menangkap semua yang ditulis oleh skrip pengendali ke aliran output standar untuk respons terhadap permintaan web. App Engine juga merekam semua yang ditulis oleh skrip pengendali ke aliran data error standar, dan menyimpannya sebagai data log. Data log untuk aplikasi Anda dapat dilihat di Konsol Google Cloud menggunakan Cloud Logging.Lingkungan runtime PHP App Engine mencakup dukungan untuk mencatat pesan arbitrer ke dalam log dari aplikasi Anda menggunakan fungsi syslog()
bawaan PHP, yang memanggil Logs API.
Lingkungan
Memaksa koneksi HTTPS
Untuk alasan keamanan, semua aplikasi harus mendorong klien untuk terhubung melalui
https
. Untuk menginstruksikan browser agar lebih memilih https
daripada http
untuk halaman tertentu atau seluruh domain, tetapkan header Strict-Transport-Security
dalam respons Anda.
Contoh:
Strict-Transport-Security: max-age=31536000; includeSubDomains
Menangani pekerjaan latar belakang asinkron
Pekerjaan latar belakang adalah pekerjaan apa pun yang dilakukan aplikasi untuk sebuah permintaan setelah Anda mengirimkan respons HTTP. Hindari melakukan pekerjaan latar belakang di aplikasi Anda, dan tinjau kode untuk memastikan semua operasi asinkron selesai sebelum Anda mengirimkan respons.
Untuk tugas yang berjalan lama, sebaiknya gunakan Cloud Tasks. Dengan Cloud Tasks, permintaan HTTP berumur panjang dan menampilkan respons hanya setelah pekerjaan asinkron berakhir.