Membangunkan Pangkalan Data Tanpa Sambungan Mati
Aplikasi terbitan di Mythex, dan pangkalan datanya, tidur apabila tiada sesiapa menggunakannya. Apabila sesuatu aplikasi bangun, ia boleh menahan permintaan pertamanya selama 10–12 saat, kerana ia cuba menggunakan semula sambungan pangkalan data yang telah mati semasa semuanya tidur. Kini kami memberikan aplikasi Spring Boot tetapan pangkalan data yang selamat merentasi tidur, dan memberitahu ejen supaya membina aplikasi bagi mana-mana tindanan dengan cara yang sama. Pada platform hos, permintaan pertama selepas bangun berubah daripada 12.7 saat kepada 2.3 saat.
Mengapa aplikasi dan pangkalan data tidur
Aplikasi terbitan Mythex berjalan pada mesin yang digantung selepas beberapa minit terbiar, dan pangkalan datanya ialah Postgres tanpa pelayan yang tidur selepas lima minit terbiar serta bangun pada pertanyaan seterusnya. Itulah yang memastikan aplikasi yang senyap kekal murah: anda dicaj mengikut apa yang sebenarnya digunakan oleh pangkalan data, dan aplikasi yang tidur tidak membelanjakan apa-apa untuk pengkomputeran. Kami menulis tentang bahagian bil dalam mengenakan bayaran untuk pangkalan data mengikut apa yang sebenarnya digunakan.
Masalahnya, kedua-duanya tidur secara berasingan, dan mereka tidak bersetuju tentang apa itu sambungan.
Gejala: lawatan pertama yang perlahan
Kebanyakan aplikasi pelayan mengekalkan kolam sambungan: beberapa sambungan pangkalan data terbuka yang sentiasa bersedia, supaya setiap permintaan tidak perlu menanggung kos membuka sambungan baharu. Itu reka bentuk yang betul untuk aplikasi yang sentiasa hidup.
Berikut ialah apa yang berlaku dengan tidur:
- Aplikasi sedang berjalan, dengan beberapa sambungan terbiar dalam kolamnya.
- Tiada siapa melawat. Mesin aplikasi itu digantung, beku dengan kolamnya utuh.
- Pangkalan data tidur dan menjatuhkan hujungnya bagi setiap sambungan.
- Seorang pelawat tiba. Aplikasi bangun tepat seperti keadaan asalnya, masih memegang sambungan yang tidak lagi diketahui oleh pangkalan data.
- Kolam menyerahkan salah satu sambungan itu. Ia perlu mengetahui bahawa sambungan itu mati, dengan mencubanya dan menunggu, sebelum ia boleh berhenti menggunakannya.
Dalam aplikasi Spring Boot, pengesahan sambungan mati itu menyekat permintaan pertama selama kira-kira 10 saat sebelum ia gagal dengan "Connection is not available". Bagi pelawat, laman itu kelihatan tergantung, dan kemudian mungkin menunjukkan ralat.
Mengapa aplikasi Spring yang paling teruk terkesan
Spring Boot ialah rangka kerja Java yang popular, dan ia menggunakan kolam sambungan bernama HikariCP secara lalai. Spring boleh mengkonfigurasi kolam itu daripada tetapan, termasuk berapa banyak sambungan terbiar yang perlu dikekalkan.
Tetapi Mythex memberikan setiap aplikasi pangkalan datanya sebagai satu DATABASE_URL dalam bentuk postgresql://user:pass@host/db. Spring tidak boleh membaca format itu secara langsung. Jadi aplikasi Spring yang dibina di Mythex sedang membina kolam sendiri dalam kod dengan menghuraikan URL itu, dan kolam yang dibina dengan tangan mengabaikan semua tetapan spring.datasource.* Spring. Walaupun seseorang tahu tetapan kolam yang betul, tiada tempat untuk ia berkesan.
Pembetulan bahagian 1: tetapan yang Spring boleh gunakan
Apabila sesebuah projek mempunyai pangkalan data, kami kini juga memberikan pembolehubah persekitaran yang dibaca secara asli oleh Spring:
SPRING_DATASOURCE_URL,SPRING_DATASOURCE_USERNAMEdanSPRING_DATASOURCE_PASSWORD, ditukar daripadaDATABASE_URL(dengan SSL diperlukan melainkan URL menyatakan sebaliknya).- Tetapan kolam yang bertahan selepas tidur:
| Tetapan | Nilai | Sebab |
|---|---|---|
| Sambungan terbiar minimum | 0 | Jangan kekalkan apa-apa terbuka antara permintaan, supaya tiada yang boleh menjadi lapuk |
| Had masa terbiar | 30 saat | Tutup sambungan yang tidak digunakan dengan cepat |
| Jangka hayat maksimum | 2 minit | Tamatkan setiap sambungan sebelum ia boleh menjadi tua |
| Had masa sambungan | 5 saat | Jangan menggantung permintaan lama jika pangkalan data lambat menjawab |
Tanpa sambungan terbiar yang dipegang, aplikasi yang bangun membuka satu sambungan baharu dan bukannya meredah sambungan mati yang banyak.
Dengan pembolehubah ini hadir, Spring mengkonfigurasi kolam itu sendiri, dan tetapan itu terpakai. Apa-apa yang telah ditetapkan oleh projek sendiri sentiasa diutamakan; kami hanya mengisi apa yang tiada. Aplikasi yang bukan Spring mengabaikan pembolehubah ini.
Butiran yang hampir menjadikannya tidak berkesan
Spring memetakan pembolehubah persekitaran kepada tetapannya mengikut peraturan yang mudah tersilap. Tetapan minimum-idle mesti ditulis sebagai SPRING_DATASOURCE_HIKARI_MINIMUMIDLE, dengan sengkang digugurkan dan perkataan dicantumkan. Menulisnya sebagai SPRING_DATASOURCE_HIKARI_MINIMUM_IDLE, yang kelihatan lebih semula jadi, dipetakan kepada tetapan lain yang tidak wujud (minimum.idle) dan diabaikan secara senyap.
Jenis kesilapan itu lulus setiap semakan dan tidak melakukan apa-apa dalam pengeluaran. Jadi satu ujian menyemak kedua-dua perkara: nilai telah ditetapkan, dan tiada pembolehubah yang menggunakan bentuk dipisahkan dengan garis bawah.
Pembetulan bahagian 2: setiap tindanan lain
Spring bukan satu-satunya rangka kerja yang mempunyai kolam, dan kami tidak boleh mengkonfigurasi setiap pustaka dalam setiap bahasa terlebih dahulu. Jadi ejen Mythex, AI yang menulis aplikasi anda, kini menerima arahan tetap untuk mana-mana tindanan: aplikasi terbitan dan pangkalan datanya tidur apabila terbiar, jadi sambungan yang dikekalkan terbuka boleh mati pada permintaan seterusnya. Ia sepatutnya:
- tidak mengekalkan sambungan pangkalan data terbiar yang terbuka, atau menyemak setiap satu sebelum digunakan,
- mencuba semula sekali apabila berlaku ralat sambungan, dan
- menggunakan tetapan pangkalan data yang disediakan oleh platform dalam persekitaran, dan bukannya membina kolamnya sendiri dengan menghuraikan
DATABASE_URL.
Perkara terakhir itu menutup gelung dengan bahagian 1: aplikasi yang dibina dengan tetapan yang disediakan secara automatik mengambil konfigurasi yang selamat untuk tidur.
Hasilnya
Diukur pada platform hos tempat kami menjalankan aplikasi terbitan, permintaan pertama selepas bangun berubah daripada 12.7 saat kepada 2.3 saat.
Apa yang kami pelajari daripadanya
- Setiap lapisan yang tidur perlu bersetuju tentang apa yang bertahan. Aplikasi yang beku dan pangkalan data yang tidur masing-masing membuat pilihan yang munasabah. Bersama-sama, aplikasi itu bangun dengan keadaan yang tidak lagi benar.
- Lalai yang direka untuk pelayan yang sentiasa hidup tidak sesuai untuk aplikasi yang diskalakan ke sifar. Mengekalkan sambungan supaya hangat ialah idea yang baik sehingga segala-galanya di sekelilingnya menjadi sejuk.
- Berikan rangka kerja data dalam format mereka sendiri. Satu URL mudah bagi kami, tetapi memaksa setiap aplikasi Spring membina kolam dengan tangan yang mengabaikan konfigurasinya sendiri.
- Uji bahawa tetapan dieja mengikut cara rangka kerja membacanya. Nilai yang betul di bawah nama yang salah tidak melakukan apa-apa, secara senyap.
Jika anda baharu dalam cara pangkalan data berfungsi di Mythex, lihat dokumentasi pangkalan data dan penerangan kami tentang apakah Postgres.