Neon Auto-Suspend

Kısaca: Veri tabanı hesaplama örneğinin bir süre istek gelmeyince otomatik olarak “uykuya daldığı” (kapandığı) Neon’a özgü bir özellik — para tasarrufu sağlar, ancak boşta kalma süresinden sonraki en ilk isteğin daha uzun sürmesi anlamına gelir, çünkü örneğin önce yeniden başlaması gerekir (“soğuk başlatma”).

Biraz daha ayrıntılı: Uykuya dalmadan önce hareketsizliğin ne kadar sürdüğü (auto-suspend zaman aşımı) ve hiç kapatılıp kapatılamayacağı (“Always Active”) Neon planına bağlıdır — daha yüksek planlar bu davranışı devre dışı bırakmaya izin verir.

Bizim bağlamımız: Emzett’in ara sıra yaşanan kesintilerinin olası katkıda bulunan nedeni olarak belirlendi, ancak kodda düzeltilemez — bu bir Neon proje ayarıdır (Dashboard → Settings → Compute) veya plan meselesidir, deponun kendisinde açık bir teknik madde değildir.

Ayrıntılı

Soğuk başlatma neden olur

Uyanma sonrası soğuk başlatma, Neon’un hesaplama örneğini (asıl Postgres sürecini) yalnızca duraklatmayıp tamamen durdurması nedeniyle olur — bir sonraki istekte bu sürecin yeniden başlatılması ve ilk sorguyu yanıtlayabilmeden önce durumunu (paylaşılan arabellekler/önbellekler, bağlantı havuzu, muhtemelen geçici nesneler) yeniden kurması gerekir. Çoğu Neon planında bu soğuk başlatma birkaç yüz milisaniye ile bir iki saniye aralığındadır — fark edilir, ancak genellikle dramatik değildir; birkaç kullanıcı aynı uyanan sürece aynı anda çarpıp isteklerin birikmesine yol açmadığı sürece (Neon gelen bağlantıları uyanırken hemen hatayla reddetmek yerine kuyruğa alır — yani istekler tamamen başarısız olmak yerine yavaşlar).

Verilerin kendisi hesaplama katmanından ayrı, kendi depolama sisteminde yaşadığı için (Neon’a bak), auto-suspend veri kaybı açısından risksizdir — yalnızca hesaplama süreci sonlandırılır, verilerin saklandığı yer değil.

Diğer “sıfıra ölçekleme” sistemleriyle karşılaştırma

Aynı “sıfıra ölçekleyerek para tasarrufu” kategorisinden ilgili bir kavram genel olarak sunucusuz hesaplamadır (örneğin Vercel Functions veya AWS Lambda’nın kendisi) — orada da benzer nedenlerle soğuk başlatmalar vardır (isteklere yanıt verebilmeden önce bir sürecin/konteynerin başlatılması gerekir). Neon’daki fark: tipik bir sunucusuz işlevde soğuk başlatma genellikle yalnızca BİR isteği etkiler (her istek potansiyel olarak yeni bir işlev örneği alır), oysa uyanan bir veri tabanında gecikme, aynı veri tabanı bağlantısında bekleyen aynı anda gelen TÜM istekleri potansiyel olarak etkiler — sonuçta veri tabanı (dal) başına yalnızca bir hesaplama örneği vardır, sunucusuz işlevlerde olduğu gibi keyfi sayıda paralel örnek değil.

Benzer ilkeye sahip diğer bulut veri tabanları: AWS Aurora Serverless v2 hesaplama kapasitesini dinamik olarak ölçekler ancak Neon’a kıyasla genellikle tamamen sıfıra kapanmaz (bir asgari kapasite etkin kalır — buna uygun olarak daha küçük tasarruf, ama gerçek bir soğuk başlatma da yok). PlanetScale (Vitess aracılığıyla MySQL uyumlu) auto-suspend’in doğrudan karşılığı olmayan farklı bir ölçekleme modeline sahiptir.

Pratikte başa çıkmak

Soğuk başlatmalardan kaçınmak isteyen/zorunda olan (örneğin gecikmeye duyarlı uygulamalar veya zaman aşımını sürekli tetikleyen sık kısa kullanım araları) birinin esasen üç seçeneği vardır: panoda auto-suspend zaman aşımını uzatmak (sorunu erteler ama çözmez), “Always Active” seçeneği olan bir plana yükseltmek (daha yüksek temel maliyet karşılığında auto-suspend’i tamamen devre dışı bırakır) ya da veri tabanını periyodik bir sağlık kontrolü isteğiyle yapay olarak “sıcak” tutmak (örneğin bir cron işiyle birkaç dakikada bir önemsiz bir sorgu çalıştırmak) — ancak sonuncusu auto-suspend’in asıl maliyet avantajını zayıflatır ve Neon’un kendisi tarafından gerçekten önerilmez.

Ayrıca bak: Neon, React.cache()