Laravel’da İşlem Havuzlamanın Anlam Kazandığı Zamanlar

Laravel uygulamanız PostgreSQL bağlantı limitleriyle karşı karşıya kalıyorsa, transaction pooling genellikle test edilmesi gereken ilk ölçekleme adımıdır. Replika oluşturmak, sharding yapmak ya da yavaş kayıt loglarında görünen her sorguyu panikle yeniden yazmak yerine. Yoğun Laravel sistemleri genellikle SQL yürütmesine nazaran bağlantı değişimi konusunda daha fazla kapasite harcarlar.

Bu nedenle PgBouncer tarzı transaction pooling ciddi PostgreSQL kurulumlarında sıkça karşımıza çıkar. PHP talepleri kısa ömürlüdür. Horizon çalışanları yük altındayken yayılır. Planlı işler ani patlamalarla gelir. Yönetici panelleri ve dışa aktarımlar çirkin zirveler oluşturur. Bu yükler, veritabanı erişimi isteyen çok sayıda istemci üretirken, bunların çoğu aslında yaşamları boyunca adanmış bir PostgreSQL arka ucuna ihtiyaç duymazlar.

Özetle: transaction pooling yalnızca uygulamanızın işlemler arasında durumsuz SQL istemcisi gibi davranması durumunda düzgün çalışır. Birçok Laravel kodu zaten bu modelle uyumludur. Uyumlu olmayan parçalar genellikle aylarca dikkatle incelenmemiş olan kısımlardır: kiralık boot mantığı, ham SQL yardımcıları, eski konsol komutları, içe aktarma işleri ya da paket bağlantı kodları.

Tavsiyem basit. Bağlantı sayısının gerçek darboğaz olduğu durumlarda transaction pooling kullanın, ancak geçişi bir yapılandırma ayarı değil, bir kod denetimi gibi ele alın. Pooling, gizli oturum düzeyi varsayımlarını ortaya çıkarmada oldukça etkilidir. İşte bu yüzden yardımcı olur ve dikkatsiz uygulamaların zarar vermesi de tam olarak bu sebepten kaynaklanır.

Darboğaz genellikle sorgu hızından önce bağlantı değişimidir

Laravel uygulamaları genellikle bu duvara sıradan bir şekilde çarpar. Bir web katmanı bir bağlantı türü açar. Horizon başka bir bağlantı açar. Planlayıcıdan gelen işler dakikada uyanır. Sonra bir rapor ihracı, toplu içe aktarma veya yanlış zamanda bir dağıtım gerçekleşir ve PostgreSQL aniden hassas görünür.

Ekipler genellikle bu anı yanlış anlar. Veritabanının yavaş olduğunu, yavaş sayfalar ve kuyruk gecikmeleri nedeniyle kullanıcıların fark ettiğini varsayarlar. Ancak PostgreSQL her arka uç işlem için gerçek bir maliyet öder: bellek, zamanlayıcı baskısı, işlem muhasebesi, boş oturum maliyeti ve genel bağlantı yönetimi. Bir veritabanı, gerçek sorgu yükü 120 havuzlanmış sunucu bağlantısında sağlıklı olsada 800 aktif bağlantıyla sağlıksız görünebilir.

Bu ayrım önemlidir çünkü çözüm farklıdır. Eğer gerçek tavan bağlantı sayısındaysa, bir havuzleyici kesinlikle büyüme alanı sunar. Kötü sorguları düzeltmelisiniz. Uygun yerlerde indeks eklemelisiniz. Ancak bu farklı bir problem.

Laravel artık bunu, pooled connections ile birlikte PostgreSQL belgelerinde açıkça ifade ediyor: Laravel veritabanı belgeleri. Bu yararlı bir sinyal. Framework, uygulama trafiği ve şema trafiği aynı bağlantı davranışını istemiyor gibi bir dersi yıllar önce zor yoldan öğrenmiş operasyon ekiplerine benzer bir şey söylüyor.

Yoğun bir Laravel uygulaması aşağıdaki semptomlar bir arada ortaya çıktığında transaction pooling için iyi bir adaydır:

• PostgreSQL bağlantı kullanımı, CPU veya I/O’dan çok daha fazla patlama yaşıyor.
• Kuyruk patlamaları ortalama talep miktarından daha fazla zarar veriyor.
• Dağıtım pencereleri veya cron yoğun dönemler, kısa ama çirkin doygunluk yaratıyor.
• Aynı zamanda çoğu talep ve iş, uzun süreli veritabanı konuşmaları yerine kısa iş birimleri.

Eğer bunlar tanıdık geliyorsa, transaction pooling erken optimizasyon değildir. Genellikle en temiz ilk düzeltmedir.

Transaction pooling gerçekten neyi değiştirir

Mechanics yeterince basittir, ancak davranışsal sonuçlar önemlidir.

Oturum havuzlama ile, tek bir istemci oturumunun ömrü boyunca bir sunucu bağlantısı alır. Transaction pooling ile, bir istemci yalnızca işlem aktif olduğu süre boyunca gerçek bir PostgreSQL arka ucunu ödünç alır ve ardından havuza geri bırakır. Bu model, patlayıcı trafikte sunucu bağlantısı yeniden kullanımını bariz şekilde artırır.

Ayrıca, uygulamanızdan gelen bir sonraki ifadenin aynı arka uç oturumuna düşeceği varsayımını da geçersiz kılar.

Takımların anlaması gereken sınır budur. PgBouncer açıkça belirtmektedir ki, transaction pooling, SET/RESET, LISTEN, PREPARE / DEALLOCATE, korunan geçici tablolar ve oturum danışmanlık kilitleri gibi oturuma bağlı özelliklerin olağan kullanımını bozar: PgBouncer özellik matrisine göz atabilirsiniz. PostgreSQL’in kendi belgeleri, bu tür bir hatanın nedenlerinden birinin şu olduğunu açıklar: PREPARE ile oluşturulan düzgün ifadeler, yalnızca mevcut sunucu oturumunun süresi boyunca yaşar: PostgreSQL PREPARE belgeleri.

Gerçek soru, Laravel’in pooling destekleyip desteklemediği değil. Destekliyor. Gerçek soru, uygulamanızın bağlantı yerel durumunu bir işlemden daha uzun süre hayatta tutup tutmadığıdır.

Genellikle iyi çalışan şeyler

Normal Laravel uygulama kodunun çoğu, transaction pooling altında fazla drama yaşanmadan hayatta kalır:

• Eloquent sorguları
• sorgu oluşturucu ile okuma ve yazma
• standart DB::transaction() blokları
• okuyup yazan, taahhüt eden ve çıkan kuyruk işleri
• bir gerçek işlem içinde kalan satır kilitleme desenleri

Bu, pooling’in genellikle Laravel ile daha iyi uyum sağlamasının sebebidir, çünkü PHP istek yaşam döngüleri zaten kısadır. Framework çoğunlukla bir iş birimi tarzı veritabanı erişimini teşvik eder.

Genellikle önce hangi parçalar kırılır

Başarısızlıklar nadiren egzotiktir. Sadece havuzlayıcının sorunu zorladığı için göz ardı edilmesi kolay şeylerdir:

• SET search_path veya benzeri oturum yapılandırması bir kez yapılmış ve sonsuza kadar varsayılmıştır.
• ham PREPARE kullanımı
• uygulama bağlantıları aracılığıyla gerçekleştirilen LISTEN/NOTIFY
• tek bir işlem sınırı dışında yeniden kullanılan geçici tablolar
• oturum danışmanlık kilitleri
• arka uç oturum bağlılığı varsaydığını sessizce varsayan uzun süreli işçi mantığı

Bu yüzden bir uygulamanın bir bölümü PgBouncer arkasında mükemmel görünebilirken, unutulmuş bir konsol komutu patlayabilir. Havuzlayıcı tutarsızlık göstermiyor. Kod tabanı, oturum davranışının uygulama mantığına sızdığını ortaya çıkarıyor.

Laravel artık size çok daha temiz bir migration yapısı sunuyor

Birkaç yıl önce, ekipler genellikle PgBouncer’ı üretim önünde itip, ortam değişkenlerini değiştiriyor ve hangi parçaların kırıldığını destek mesajlarını okuyarak öğreniyorlardı. Laravel’in daha yeni pooled Postgres desteği, size bunun için daha iyi bir model sunuyor.

Pratik bir yapılandırma şu şekilde görünür:

'pgsql' => [
            'driver' => 'pgsql',
            'url' => env('DB_URL'),
            'host' => env('DB_HOST'),
            'port' => env('DB_PORT', '5432'),
            'database' => env('DB_DATABASE'),
            'username' => env('DB_USERNAME'),
            'password' => env('DB_PASSWORD'),
            'charset' => 'utf8',
            'prefix' => '',
            'prefix_indexes' => true,
            'search_path' => 'public',
            'sslmode' => 'prefer',
            'pooled' => env('DB_POOLED', true),
            'direct' => array_filter([
                'host' => env('DB_DIRECT_HOST'),
                'port' => env('DB_DIRECT_PORT', '5432'),
                'username' => env(),
                'password' => env('DB_DIRECT_PASSWORD'),
                'sslmode' => env(, ),
            ]),
        ],

Bu yapı şunlar için iki önemli nedenle önemlidir.

Birincisi, Laravel havuzlu mod aktif olduğunda doğrudan bağlantıyı otomatik olarak migration, şema dökümü, kurtarma, db:wipe, db:show ve ilgili komutlar için kullanabilir. Bu doğru varsayımdır. DDL ve bakım iş akışları, transaction pooling’in en az hoş olduğu yerlerdir.

İkincisi, Laravel emüle edilmiş hazırlıkları pooled bağlantılar için etkinleştirir. Bu rastgele bir framework detayıdır. Laravel, PgBouncer belgelerinde işaret edilen uyum çizgisini tanımaktadır. Eğer kodunuz yerel oturum düzeyindeki hazırlık mantığına bağımlıysa, havuz bağlantısı kurallarınızı değiştirir.

Operasyonel kural acımasızca basit olmalıdır:

Uygulama trafiği havuz üzerinden geçer. Şema ve bakım işleri doğrudan bir yol alır.

Koddan bu doğrudan yolu ihtiyaç duyduğunuzda, bunu açık hale getirin:

use Illuminate\Support\Facades\DB;

DB::connection()->statement(
    );

Bu açıklık önemlidir. Gizli altyapı istisnaları, geri alımları ve geç saat onarımlarını beklenenden daha zor hale getiren şeylerdir.

Çoğu ekip tarafından göz ardı edilen Laravel’e özel tuzaklar

Aşikar tuzak ham PREPARE. Daha yaygın tuzaklar daha incelikli ve çoğu zaman daha pahalıdır.

SET arkasında gizli kiralık veya şema boot mantığı

Bazı çok kiracılı veya çok şemalı uygulamalar, middleware, bir kiracı çözümü veya düşük seviyeli bir yardımcıda SET search_path kullanır. Bu, bir uygulama bağlantısının etkin olarak bir arka uç oturumunu koruduğu durumda yıllarca iyi çalışıyor gibi görünebilir. Transaction pooling altında bu varsayım kaybolur.

Eğer şema bağlamı önemliyse, bu niyeti dayanıklı bağlantı yapılandırmasına veya açık SQL tasarımına taşıyın. Oturum yerel ayarları, sunucu bağlantıları paylaşıldığında güvenilir bir sözleşme değildir.

Mini veritabanı oturumları gibi davranan işçiler

Pek çok kuyruk işi PgBouncer arkasında oldukça güvenlidir. Tehlikeli olanlar, mini oturum odaklı betikler gibi davranan işçilerdir.

Bu genellikle şunları barındıran işler anlamına gelir:

• geçici tablolar oluşturma
• danışmanlık kilitlerine kayıtsız bir şekilde bağımlı olma
• dış API’ler çağrılırken işlemleri açık tutma
• birden fazla ifadenin arka uç özel durumunu korumasını bekleme

Bu, işçiler ve transaction pooling’in karışmadığı anlamına gelmez. Genelde iyi karışırlar. Ancak kötü yapılandırılmış işçiler, havuzlayıcı arka uç bağlılığını kaldırdığında göz ardı edilmesi imkansız hale gelir.

Laravel sticky ile oturum bağlılığının karıştırılması

Laravel’in okuma/yazma sticky seçeneği kullanışlıdır, ancak ekipler genellikle bunun onlara ne kazandırdığından fazla okur. Belgeler nettir: Eğer bir yazım mevcut istek döngüsü sırasında gerçekleşirse, sonraki okuma aynı istekte yazım bağlantısını kullanır: sticky seçeneği.

Bu, şu anlama gelmez:

• gelecek istekler aynı arka uç oturumunu korur
• kuyruk işçileri HTTP isteklerinden yazınızı okuma garantilerini devralır
• replica gecikmesi önemli hale gelmez
• transaction pooling durumsaldır

Bu karışıklık önemlidir çünkü ekipler bazen havuzlamayı, aslında tutarlılık veya yönlendirme sorunları olan hatalar için suçlamaktadır. Bu, birbirine yakın endişelerdir, aynı endişe değildir.

Artık kimsenin sahip olmadığı eski komutlar

En yüksek riskli kod genellikle kontrollerde veya hizmet sınıflarında değil. Eski Artisan komutları, yönetici onarım betikleri, rapor üreticileri, içe aktarma araçları veya paket entegrasyon kodu gibi yerlerde yer alır. Bu yerler tam olarak geçici tablolar, LISTEN, oturum ayarlamaları veya tuhaf işlem varsayımları gizlenir.

Eğer migration denetiminiz büyük ölçüde tarayıcı tıklamaları ise, sistemin en güvenli dilimini doğruluyorsunuz demektir.

Geçiş öncesi gerçek bir Laravel kod tabanını nasıl denetlerim

Doğru yaklaşım basittir: gizli oturum bağlantısının var olduğunu varsayın, bunu kanıtlayana kadar.

Blunt bir arama ile başlayın:

rg -n "SET |LISTEN|NOTIFY|PREPARE|DEALLOCATE|pg_advisory_lock|pg_try_advisory_lock|create temp|search_path" app/ bootstrap/ config/ database/ routes/ tests/

Bu arama kasıtlı olarak çirkin. Hızlı bir şekilde şüpheli desenleri yakalamak içindir, slayt takımı için şık görünmek değil.

Ardından, sıradan istek işleme ile en az benzer olan sistemin kısımlarını gözden geçirin:

• içe ve dışa aktarımlar
• ham SQL raporlama işleri
• planlı bakım komutları
• ağ çağrılarla işlem karıştıran işçiler
• kısmi yan etkilerle yoğun yeniden denemeleri olan işler

Bulduğum şeyleri üç sepete sınıflandırırdım:

1. Havuzdan güvenli: sıradan uygulama trafiği, standart işlemler, basit işler.
2. Gözden geçirilmesi gerekiyor: ham SQL, tuhaf işçiler, şema duyarlı akışlar, geçici tablolar, danışmanlık kilidi kullanımı.
3. Yalnızca doğrudan: migration, uzantı kurulumu, şema onarımı, operasyonel bakım araçları.

Böyle bir sınıflandırma, geçişi varsayımdan politikaya dönüştürür. Ayrıca, kaçınılmaz istisna yollarını erken fark edilmesini sağlar, bir olay sırasında değil.

Kendinize yalan söylemeden geçişi nasıl test edersiniz

Özellik testleri tek başına yeterli değildir. Geçiş, eşzamanlılık altında veritabanı bağlantılarının nasıl tahsis edildiğini değiştirir, bu nedenle doğrulamanın bu şekli uygulaması gerekir.

Hedefler basittir:

1. normal havuzlu uygulama trafiği yine de doğru davranır
2. doğrudan yol operasyonel görevleri hala çalışır
3. bağlantı baskısı kötü bir yere taşınmadan düşer

Geçiş dikişine yönelik küçük bir işle ilişkili bir yan suite, burada büyük genel bir suite’ye göre daha faydalıdır:

it(, function () {
            DB::transaction(function () {
                DB::table()->insert([
                    => ,
                    => ,
                ]);

                $order = DB::table()
                    ->where(, )
                    ->lockForUpdate()
                    ->first();

                expect($order->status)->toBe();
            });
        });

        it(, function () {
            expect(fn () => DB::connection()
                ->statement())
                ->not->toThrow(Exception::class);
        });

Daha sonra üretime benzer trafiğin altında havuzu sahneleyin, yalnızca kibar bir demo değil:

• eşzamanlı HTTP istekleri
• Horizon patlamaları
• planlayıcı pencereleri
• paneller ve dışa aktarımlar

Ve gerçekten önemli olan sinyalleri izleyin:

• aktif PostgreSQL sunucu bağlantıları
• ani patlamalar ve dağıtımlar sırasında bağlantı değişimi
• PgBouncer bekleme süresi ve havuz doygunluğu
• kuyruk gecikmesi ve yeniden deneme davranışı
• işçi özel veya ham SQL hata oranları

Eğer gecikme kabul edilebilir kalırken PostgreSQL bağlantı baskısı önemli ölçüde düşerse, bu gerçek bir kazançtır. Eğer PgBouncer, kuyruğun bir darboğazı haline gelir veya uzun işlemler, verimliliği açlığa mahkûm ederse, en azından bunu üretim trafiği zorlamadan öğrenmiş olursunuz.

Ayrıca bir geri dönüş tatbikatı yapın. Geçiş yapılmadan önce, havuz bırakıldığında doğrudan yol geçişlerinin ve bakım komutlarının hala çalıştığını kanıtlayın. Bu adım sıkıcıdır, ancak geri alımın ikinci bir kesintiye dönüşmesini engelleyen türden bir sıkıcı adımdır.

Pratik Kural

Yoğun Laravel uygulamaları için, transaction pooling genellikle bağlantı sayısının gerçek darboğaz olduğu ve uygulamanın çoğunlukla kısa, durumsuz SQL iş birimleri gibi davrandığı durumlarda doğru hamledir. Kod tabanı hala asla doğru bir şekilde izole edilmemiş bağlantı yerel davranışlara bağımlıysa, bunu erteleyin.

Gerçek kazançlar mevcuttur. PostgreSQL, yararlı sorguları yürütmek için daha fazla zaman harcıyor ve boş ya da dalgalı istemci oturumlarını yönetmek için daha az zaman harcıyor. Kuyruk patlamaları daha az israf haline geliyor. Dağıtım pencereleri daha sakinleşiyor. Ancak ekipler yalnızca veritabanı oturumunun uygulama durumlarının bir parçası olmadığını göz ardı etmeyi bıraktıklarında bu faydaları elde ederler.

Hatırlanması gereken ders şudur: agresif bir şekilde havuz yapın, ancak veritabanı oturum durumunu bir yük olarak görmekten vazgeçmeyin, aksi takdirde gerçekten gerekli olduğunu kanıtlamadığınız sürece.

Tam yazıyı QCode’da okuyun: https://qcode.in/postgres-transaction-pooling-lessons-for-busy-laravel-apps/