Laravel Performans Optimizasyonu: Üretim Uygulamaları İçin 20 Hızlı Kazanım

Performans, sonradan eklenen bir özellik değildir. Uygulamanızın geliştirilmesi sırasında yapılan yüzlerce küçük kararın toplamıdır. Ancak mevcut bir Laravel uygulamanız yavaşsa, iyi haber şu ki çoğu performans problemi için iyi bilinen çözümler bulunmaktadır ve bunların birçoğu bir öğleden sonrasında uygulanabilir.

Bu 20 optimizasyon, etki-güç oranına göre sıralanmıştır. İlk birkaç madde dakikalar içinde yapılabilir ve dramatik iyileşmeler sağlayabilir. Daha sonrakiler daha fazla çalışma gerektirir ancak uygulamanızın yapısal sorunlarını ele alır.

Buradaki her optimizasyon, Deploynix üzerinde çalışan üretim Laravel uygulamaları üzerinde doğrulanmıştır. İlgili olduğunda, her optimizasyonun nasıl desteklendiğini belirteceğiz.

Caching and Compilation

1. Cache Your Configuration

Laravel uygulamanız her başlatıldığında, diskten onlarca konfigürasyon dosyasını okur, bunları birleştirir ve ortam değişkenlerini çözer. php artisan config:cache komutu, tüm konfigürasyonu tek bir dosyaya derleyerek yükleme süresini çok kısaltır.

Bunu Deploynix dağıtım scriptinize ekleyin, her dağıtımdan sonra çalışsın. İyileşme hemen fark edilecektir: konfigürasyon yükleme süresi birkaç milisaniyeden bir milisaniyenin altına düşer. Tek dikkat edilmesi gereken, konfigürasyon dosyaları dışındaki env() çağrılarını kullanamayacak olmanızdır, çünkü .env dosyası artık okunmaz.

2. Cache Your Routes

Yol kaydı, büyük uygulamalarda oldukça maliyetlidir. 200 rotaya sahip bir uygulama, her istekte rota tanımlarını ayrıştırmak, regex desenlerini derlemek ve middleware’i kaydetmek açısından anlamlı zaman harcar. php artisan route:cache komutu, tüm rota tablosunu tek bir dosyaya seri hale getirir.

Bu etkinin büyüklüğü rota sayınızla orantılıdır. Yüzlerce rotaya sahip uygulamalarda rota kaydı süresi 50+ milisaniyeden 5 milisaniyenin altına düşer. php artisan route:cache komutunu Deploynix dağıtım scriptinize ekleyin, config:cache komutunun hemen ardından.

3. Cache Your Views

Blade şablonları ilk erişimde PHP’ye derlenir. php artisan view:cache komutu, her Blade şablonunu önceden derleyerek dağıtımdan sonraki ilk isteğin derleme maliyetini ödememesi sağlar. Etki, dağıtım sonrasında görünüm önbelleği soğukken hemen fark edilecektir.

4. Cache Your Events

php artisan event:cache komutu, tüm olay dinleyicilerinin önceden keşfedilmesini sağlar, böylece Laravel her istekte uygulama dizinlerini taramak zorunda kalmaz. Bu küçük bir optimizasyondur ama uygulaması için hiçbir maliyet yoktur.

5. Optimize Composer Autoloading

Produksiyon ortamında composer install --optimize-autoloader --no-dev komutunu çalıştırın. --optimize-autoloader bayrağı, PSR-4 otomatik yüklemesini bir sınıf haritasına dönüştürerek, dosya sistemi aramalarını önleyerek daha hızlı hale getirir. --no-dev bayrağı ise geliştirme bağımlılıklarını hariç tutar, bu da otomatik yükleyicinin bilmesi gereken sınıf sayısını azaltır.

Database Optimization

6. Fix N+1 Query Problems

N+1 sorguları, Laravel uygulamalarındaki en yaygın performans sorunudur. Bir model koleksiyonu yüklerken, her birindeki bir ilişkiye erişmek ayrı bir sorgu tetikler. 50 yazıyı yazarları ile birlikte yüklemek 51 sorgunun tetiklenmesine neden olur.

Bunu çözmek için eager loading kullanın: Post::with('author')->get(). Laravel ayrıca bu sorunları bulmanıza yardımcı olabilir: geliştirme sırasında Model::preventLazyLoading()‘i AppServiceProvider‘ın boot metodunda ekleyin. Bu, her lazy-loaded ilişkiye erişildiğinde bir istisna fırlatır.

7. Add Missing Database Indexes

Uygulamanız bir WHERE, ORDER BY veya JOIN ifadesinde bir sütunu sorguluyorsa, o sütunun bir indekse sahip olması gerekir. Eksik indeksler, veritabanının verimli indeks aramalarını kullanmak yerine tüm tabloları taramasına neden olur.

Ağır sorgularınıza EXPLAIN komutunu çalıştırarak eksik indeksleri belirleyin. Bunları eklemek için migrate işlemleri oluşturun. Deploynix üzerinde, bu migre işlemlerini dağıtım scriptinizin bir parçası olarak çalıştırabilir ve veritabanı sunucunuza otomatik olarak uygulayabilirsiniz.

İndeks için yaygın adaylar: yabancı anahtar sütunları (user_id, team_id), filtrelerde bulunan durum sütunları, sıralama için kullanılan zaman damgaları ve herhangi bir unique doğrulama kuralında kullanılan sütunlardır.

8. Select Only the Columns You Need

User::all() ifadesi, kullanıcılar tablosundaki her sütunu seçer; oysa sadece isim ve e-posta ihtiyacınız olabilir. User::select(['id', 'name', 'email'])->get() kullanarak veritabanından taşınan veri miktarını ve modellerinizin kullandığı bellek miktarını azaltabilirsiniz.

Bu, büyük metin sütunları, JSON sütunları veya birçok sütun için özellikle etkili olur. 30 sütundan yalnızca 5’ine ihtiyaç duyduğunuzda, 6 kat fazla veri transferi sağlanmaktadır.

9. Use Database Query Caching

Nadiren değişen veriler (ayarlar, kategoriler, özellik bayrakları, izinler) için sorgu sonuçlarını önbelleğe alın, böylece her istekte veritabanına erişmek zorunda kalmazsınız. Laravel’in önbellek sistemi doğaldır:

$categories = Cache::remember('categories', 3600, function () {
    return Category::all();
});

Deploynix üzerinde Valkey’i hızlı ve güvenilir önbellekleme için yapılandırabilirsiniz. Valkey Redis uyumlu olduğundan, tüm Laravel Redis önbellek sürücüleri kutudan çıktığı gibi çalışır.

10. Paginate Large Result Sets

Kullanıcıya sınırsız koleksiyonlar döndürmekten kaçının. Bir tablo 10,000 satıra sahipse, Model::all() hepsini belleğe yükler. Model::paginate(25) veya Model::cursorPaginate(25) kullanarak yalnızca mevcut sayfa için gereken satırları yükleyin.

Cursor pagination, büyük veri setleri için daha verimli olduğundan COUNT(*) sorgusu gerektirmez. API uç noktaları ve toplam sayının gerekli olmadığı sonsuz kaydırma arayüzleri için kullanın.

Queue and Background Processing

11. Offload Slow Operations to Queues

100 milisaniyeden daha uzun süren herhangi bir işlem, arka plan işleme için aday olmalıdır. E-posta gönderimi, PDF oluşturma, görüntü işleme, üçüncü taraf API çağrıları, rapor oluşturma ve webhook iletimi gibi işlemler kuyruk işlerine aktarılabilir.

Deploynix üzerinde, kuyruk işçilerini uygulama sunucusunda daemon olarak çalıştırın veya daha iyisi, kuyruk işlemleri için özel İşçi sunucuları temin edin. Bu, arka plan işlerini web isteklerinin işlenmesinden izole ederek, kullanıcıların yanıt sürelerini ağır arka plan işlemlerinden etkilenmemesini sağlar.

12. Batch Queue Jobs When Possible

1,000 bildirim e-postası göndermeniz gerekiyorsa, 1,000 ayrı iş emri vermek, iş serileştirme, kuyruk yönetimi ve işçi polling’de ek maliyet oluşturur. İlgili işleri gruplamak için Laravel’in Bus::batch() özelliğini kullanın. Gruplar, yerleşik ilerleme takibi, hata yönetimi ve tamamlama geri çağırmaları sağlar.

13. Configure Queue Timeouts and Retries

Kuyruk işçilerinizde uygun --timeout ve --tries değerlerini ayarlayın. Sonsuz bir şekilde bekleyen bir iş, bir işçi sürecini meşgul eder. Kalıcı bir hatada sonsuz bir şekilde yeniden deneyen bir iş, kaynakları boşa harcar. Bu değerleri işlerinizin beklenen sürelerine ve hata durumlarına göre yapılandırın.

PHP and Server Tuning

14. Enable and Tune OPcache

OPcache, derlenmiş PHP bayt kodunu paylaşılan bellekte önbelleğe alır, bu sayede her istek için PHP dosyalarını ayrıştırma ve derleme ihtiyacını ortadan kaldırır. Bu, PHP seviyesindeki en etkili optimizasyondur.

Prodüksiyon için anahtar ayarlar: opcache.enable=1, opcache.memory_consumption=256 (MB), opcache.max_accelerated_files=20000, ve opcache.validate_timestamps=0. Son ayar, OPcache’in dosyaların değişip değişmediğini kontrol etmemesini belirtir, bu üretimde güvenlidir çünkü dosyalar değiştiğinde yeniden dağıtım yaparsınız. Deploynix, her dağıtımdan sonra PHP-FPM’i otomatik olarak yeniden başlatarak OPcache’i geçersiz kılar.

15. Tune PHP-FPM Worker Count

PHP-FPM’ın pm.max_children ayarı, sunucunuzun kaç eşzamanlı PHP isteği işleyebileceğini belirler. Formül: mevcut bellek bölünmüş olan bellek miktarı. 4 GB RAM’e sahip bir sunucu, Nginx, veritabanı ve işletim sistemi için 2 GB kullanılabilir olup, ortalama 40 MB bellek harcayan proseslerle 50 eşzamanlı işçi barındırabilir.

Deploynix otomatik olarak pm = dynamic olarak yapılandırır; bu performans ve bellek verimliliğini dengeler. Sürekli trafiğe sahip özel App sunucuları için pm = static ya da daha tutarlı performans sağlamak amacıyla değişiklik yapabilirsiniz, ancak daha yüksek boşta bellek kullanımı ile ilişkilendirilir.

16. Consider Laravel Octane

Laravel Octane, uygulamanızı istekler arasında bellekte tutarak her gelen geleneksel PHP-FPM isteğindeki başlatma maliyetini ortadan kaldırır. Deploynix, Octane ile FrankenPHP, Swoole ve RoadRunner sürücülerini destekler.

Octane, ağır başlatma maliyeti olan uygulamalar için yanıt sürelerini %50-80 oranında azaltabilir. Ancak, bellek sızıntılarına, statik duruma ve hizmet sağlayıcı davranışına dikkat edilmesi gerekir. Üretime geçmeden önce kapsamlı testler yapmanız önerilir.

Frontend and Asset Optimization

17. Use a CDN for Static Assets

CSS, JavaScript, resimler ve fontlarınızı bir CDN üzerinden sunun. Bu, sunucunuzdan olan trafiği azaltır ve varlıkların kullanıcılarınıza daha yakın kenar konumlarından teslim edilmesini sağlar. Deploynix ortamınızda ASSET_URL ortam değişkenini CDN’nizin URL’sine ayarlayın.

Vite’nin yerleşik varlık versiyonlaması, tarayıcıların varlıklarınızı her zaman en son sürümü yüklemesini sağlarken, aynı zamanda onları etkili bir şekilde önbelleğe alır.

18. Enable Response Compression

Nginx’i HTML, CSS, JavaScript, JSON ve XML yanıtlarını Gzip veya Brotli ile sıkıştıracak şekilde yapılandırın. Sıkıştırılmış yanıtlar %60-80 daha küçüktür, bu da bant genişliği kullanımını azaltır ve yükleme sürelerini iyileştirir, özellikle de yavaş bağlantılardaki kullanıcılar için.

Deploynix’in Nginx yapılandırması varsayılan olarak sıkıştırmayı içerir, ancak yanıt türlerinizin kapsandığından emin olun.

Application-Level Optimization

19. Use Lazy Collections for Large Datasets

Büyük veri setlerini işlerken (CSV içe aktarımları, toplu işlemler, rapor üretilmesi), Laravel’in LazyCollection veya cursor() kullanan kayıtları bellek dolmadan işlemek için kullanın:

User::cursor()->each(function (User $user) {
        // İşlemenin bir kullanıcıdan başlayın
        });
        

Bu, veri kümesinin boyutuna bakılmaksızın bellek kullanımını sabit tutar. all() ile bellekle çektiğiniz bir milyon satırlık bir ürün, cursor() ile sorunsuz çalışır.

20. Profile Before Optimizing

Bu aslında madde sıfır olmalı ama diğerlerinin nasıl yönetileceğini belirleyen ilke olarak sonuncu sıraya konmuştur. İçgüdüye dayalı olarak optimize etmeyin. Uygulamanızı Laravel Telescope, Debugbar (sadece geliştirmede) veya Clockwork gibi araçlarla profilleyin.

5 milisaniyede çalışan bir sorguyu optimize etmeye çalışırken, her isteğin 200 milisaniye ekleyen bir middleware’i görmezden gelmiş olabilirsiniz. Profilleme, çabanızı maksimum etki için nerede yoğunlaştıracağınızı belirler.

Deploynix Infrastructure Tips

Uygulama düzeyindeki optimizasyonların ötesinde, Deploynix üzerindeki altyapı seçimleriniz performansı önemli ölçüde etkiler.

Ayrı bir Veritabanı sunucusu kullanın. Aynı sağlayıcı üzerindeki uygulama sunucunuz ve veritabanı sunucunuz arasındaki ağ gecikmesi genellikle 1 milisaniyenin altındadır. Ayrı veritabanı kaynaklarının faydası, bu küçük gecikme maliyetinden çok daha fazladır.

Ayrı bir Önbellek sunucusu kullanın. Valkey kendi sunucusunda, önbellek işlemleri uygulamanız veya veritabanıyla bellek ve CPU için rekabet etmez.

Kuyruk işlemleri için İşçi sunucuları kullanın. Arka plan işlerinin, web talepleri ile CPU ve bellek için rekabet etmemesi gerekir. Özel İşçi sunucuları, her ikisi için de tutarlı performans sağlar.

Yatay ölçekleme için Yük Dengeleyici kullanın. Dikey ölçekleme sınırına ulaştığınızda, Deploynix Yük Dengeleyici arkasında daha fazla Web sunucusu ekleyin. Stateless uygulamalar için Round Robin, değişken istek süreleri için Least Connections veya oturum bağlılığı için IP Hash seçin.

Sunucularınızı doğru şekilde boyutlandırın. Deploynix, DigitalOcean, Vultr, Hetzner, Linode, AWS ve özel sağlayıcılar arasında kullanım sağlar. Farklı sağlayıcılar, CPU-tabanlı ve bellek-tabanlı iş yükleri için farklı fiyat-performans oranları sunar. Sağlayıcınızı iş yükünüze göre seçin.

Measuring Success

Bu optimizasyonları uyguladıktan sonra sonuçları ölçün. Uygulamanızın yanıt süresi yüzdellerini (p50, p95, p99), her istekteki veritabanı sorgu sayısını, her istekteki bellek kullanımını ve sunucunuzun CPU ve bellek kullanımını Deploynix’in gerçek zamanlı izleme aracıyla takip edin.

Deploynix sağlık uyarılarını ayarlayın, böylece performans kötüleştiğinde bilgilendirin. Yanıt sürelerinde veya kaynak kullanımında ani bir artış, genellikle bir güncellemenin ardından ortaya çıkan performans gerilemesini işaret eder. Deploynix’in geri alma özelliği, bilinen iyi bir dağıtıma hızlıca geri dönmenizi sağlar.

Conclusion

Performans optimizasyonu, tek seferlik bir proje değil, sürekli bir uygulamadır. Bu listedeki en etkili öğelerden başlayın, çünkü en büyük etkiyi en az çaba ile sağlar. Daha sonra, uygulamanızın ihtiyaçlarına göre aşağıya inin.

En etkili optimizasyonlar genellikle en basit olanlardır: yapılandırmanızı önbelleğe alın, N+1 sorgularınızı düzeltin, eksik indeksler ekleyin ve yavaş işleri kuyruklara aktarın. Bu dört madde bile yavaş bir uygulamayı hızlı bir uygulamaya dönüştürebilir.