Salesforce platformunda kod geliştirirken, production ortamında beklenmedik hatalarla karşılaşmak ve tüm işlemlerin aniden durması can sıkıcı bir deneyimdir. Salesforce Governor Limit, çok kiracılı bulut mimarisinde bu tür aksaklıkları önleyen ve platform performansını koruyan kısıtlama mekanizmalarıdır. Bu rehberde limit türlerini, önemini, sık karşılaşılan hataları ve optimizasyon stratejilerini detaylıca inceleyeceğiz.
Salesforce Governor Limit Tanımı
Salesforce Governor Limit, bulut tabanlı çok kiracılı (multi-tenant) mimaride adil kaynak dağılımını garantilemek amacıyla platforma yerleştirilmiş sistem kısıtlamalarıdır. Bu limitler, tek bir işlem veya organizasyonun platform kaynaklarını tekelleştirmesini önleyerek tüm kullanıcılar için dengeli bir performans ortamı yaratır.
Salesforce ekosisteminde her Apex transaction, SOQL sorgusu, DML operasyonu ve API çağrısı belirli sınırlar dahilinde çalışmak zorundadır. Kod bu sınırları aştığı anda sistem otomatik olarak işlemi durdurur ve işlenemeyen bir runtime exception fırlatır. Salesforce resmi dokümantasyonuna göre, tek bir senkron Apex transaction içinde maksimum 100 SOQL sorgusu ve 150 DML işlemi gerçekleştirilebilir.
Platform üzerinde çalışan binlerce organizasyon aynı altyapıyı paylaşır. Salesforce Governor Limit mekanizması sayesinde, verimsiz yazılmış bir kodun tüm sistem performansını olumsuz etkilemesi engellenir.
Geleneksel yerinde sistemlerde sunucu kapasitesinin tamamı tek bir müşteriye aitken, bulut mimarisinde bu kaynaklar binlerce müşteri arasında paylaştırılır ve bu paylaşımın adaletli olması gerekir.
Salesforce Governor Limit iki ana kategoriye ayrılır:
- Hard limits (değiştirilemez limitler)
- Soft limits (belirli koşullarda artırılabilir limitler)
SOQL ve DML limitleri hard limit kategorisindeyken, Apex kod boyutu (varsayılan 6MB) gibi bazı limitler Salesforce desteğine başvurularak artırılabilir.
Salesforce Governor Limit Türleri
Salesforce platformu, farklı kaynak kullanım senaryoları için çeşitli limit kategorileri tanımlar. Her kategorinin kendine özgü kontrol mekanizmaları ve eşik değerleri bulunur.
| Limit Türü | Açıklama | Uygulama Alanı |
| Per-Transaction Apex Limits | Her Apex transaction için geçerli limitler. Batch Apex’te her batch çalıştırmasında sıfırlanır. | SOQL sorguları (100), DML işlemleri (150), Heap boyutu (6MB senkron / 12MB asenkron) |
| Per-Transaction Certified Managed Package Limits | ISV partnerların geliştirdiği ve AppExchange güvenlik incelemesinden geçmiş paketler için ayrı limitler. | Namespace başına 100 SOQL, kümülatif limit 1,100’e kadar çıkabilir |
| Lightning Platform Apex Limits | Apex transaction’larına özgü olmayan, platform seviyesinde zorlanan limitler. | API çağrıları, e-posta gönderim limitleri |
| Static Apex Limits | Tüm transaction’larda geçerli olan statik limitler. | Apex kod boyutu (6MB), trigger ve döngü boyutları |
| Size-Specific Apex Limits | Kod boyutuyla ilgili kısıtlamalar. | Class ve trigger boyut limitleri |
Salesforce Edition’a bağlı olarak bazı limitler değişiklik gösterir. Professional Edition’da 50 custom object oluşturulabilirken, Unlimited ve Performance Edition’larda bu sayı 2,000’e kadar çıkar. API çağrı limitleri de lisans sayısına ve Edition’a göre farklılaşır.
Senkron ve asenkron işlemler arasında da önemli farklar vardır. Asenkron işlemlerde (Future methods, Batch Apex, Queueable) genellikle daha yüksek limitler tanımlanmıştır. Örneğin, senkron bir transaction’da 100 SOQL sorgusu limiti varken, asenkron işlemlerde bu sayı 200’e çıkar. CPU zaman limiti senkron işlemlerde 10 saniye iken, asenkron işlemlerde 60 saniyeye uzar.
Multi-Tenancy Mimarisi ve Kaynak Yönetimi
Salesforce platformunun temelinde yatan multi-tenancy mimarisi, birden fazla müşterinin aynı fiziksel altyapıyı paylaşmasına olanak tanır. Tek bir Salesforce instance (pod veya server olarak da bilinir) üzerinde on binlerce organizasyon barınabilir.
Bu mimari yapı, maliyet verimliliği ve yönetim kolaylığı sağlarken beraberinde önemli bir zorluk getirir. Kaynak paylaşımının adil ve sürdürülebilir olması gerekir. Geleneksel yazılım mimarilerinde her müşterinin kendi sunucusu vardır ve tüm CPU, bellek, ağ ve veritabanı kaynakları o müşteriye aittir. Bulut mimarisinde ise bu kaynaklar binlerce kullanıcı arasında dinamik olarak dağıtılır.
Salesforce Governor Limit, bu kaynak dağılımını düzenleyen trafik polisi gibi çalışır. Platform, her transaction’ın ne kadar CPU zamanı kullanabileceğini, kaç veritabanı sorgusu çalıştırabileceğini ve ne kadarlık bellek alanı tahsis edebileceğini önceden belirler. Verimsiz yazılmış bir kod bu limitleri aşmaya çalıştığında, sistem operasyonu durdurarak diğer kullanıcıların performansını korur.
Kaynak izolasyonu prensibi, bir organizasyondaki kötü performans gösteren kodun başka organizasyonları etkilememesini sağlar. Her müşteri, kendisine tahsis edilen kaynak dilimini kullanır ve bu dilim içinde kalması beklenir. Platform ölçeklenebilirliği de bu sayede garanti altına alınır, çünkü her transaction’ın tüketeceği maksimum kaynak miktarı önceden bilinir ve planlanabilir.
Salesforce Governor Limit Önemi ve İş Süreçlerine Etkisi
Salesforce Governor Limit mekanizması, platform üzerinde geliştirme yapan herkes için kritik öneme sahiptir. Bir limit aşımı gerçekleştiğinde, sistem işlenemeyen bir exception fırlatır ve tüm transaction geri alınır. Bu durum, canlı ortamda çalışan iş süreçlerinin aniden durmasına neden olabilir.
Örneğin, toplu veri güncellemesi yapan bir trigger’ın Salesforce Governor Limit’e takılması durumunda, kullanıcılar kayıtlarını güncelleyemez hale gelir. Bir entegrasyon senaryosunda API çağrı limitinin aşılması, harici sistemlerle veri senkronizasyonunun durmasına yol açar. Günlük e-posta limitinin (organizasyon başına 5,000 dış e-posta adresi) aşılması ise müşteri iletişim süreçlerini kesintiye uğratır.
Performans açısından bakıldığında, Salesforce Governor Limit verimliliği zorunlu kılar. Geliştiriciler, kodu yazarken kaynak optimizasyonunu düşünmek zorundadır. Döngü içinde SOQL sorgusu yazmak veya her kayıt için ayrı DML işlemi gerçekleştirmek gibi kötü pratikler, limit aşımına yol açar. Bu zorunluluk, sonuç olarak daha kaliteli ve performanslı kod yazılmasını teşvik eder.
İş sürekliliği perspektifinden değerlendirildiğinde, bu limitler sistem stabilitesini garanti eder. Salesforce platformunda milyonlarca işlem her saniye gerçekleşir ve hiçbir müşteri diğerlerini olumsuz etkileyemez. Bir organizasyonun verimsiz kodu, sadece kendi transaction’ını etkiler; platform genelinde bir performans düşüşü yaratmaz.
Ölçeklenebilirlik açısından ise, Salesforce Governor Limit mekanizması olmadan platformun bu büyüklükte büyümesi mümkün olmazdı. Şirketler büyüdükçe ve veri hacimleri arttıkça, kod tabanının bu büyümeye uyum sağlaması gerekir. Limitler sayesinde, küçük veri setleriyle çalışırken göz ardı edilen performans sorunları erken aşamada tespit edilir ve çözülür.
En Sık Karşılaşılan Governor Limit Hataları
Salesforce geliştiricilerin karşılaştığı en yaygın limit aşımı senaryoları belirli kalıplar etrafında toplanır. Bu hataları tanımak, önleyici tedbirler almanızı kolaylaştırır:
- SOQL 101 Hatası (Too Many SOQL Queries): Döngü içinde SOQL sorgusu çalıştırıldığında ortaya çıkan klasik hatadır. Örneğin, her account kaydı için ilgili contact’ları sorgulamak gibi senaryolarda, 100 account bulunduğunda limit anında aşılır. Bu hata, tek bir transaction’da 100 SOQL sorgusunu aşan kodlarda karşınıza çıkar ve geliştiriciler arasında en çok rastlanan sorunlardan biridir.
- DML 151 Hatası (Too Many DML Statements): Döngü içinde insert, update veya delete işlemleri yapıldığında, 150 DML limiti kolayca aşılır. Her iterasyonda yeni bir kayıt oluşturmak veya güncellemek yerine, tüm kayıtların bir koleksiyonda toplanıp tek seferde işleme alınması gerekir. Toplu veri operasyon senaryolarında bu hatanın önüne geçmek kritiktir.
- Heap Size Limit Exceeded: Büyük veri setlerini bellekte tutmaya çalışan kodlar, senkron transaction’larda 6MB heap limitini aşabilir. Özellikle List veya Map koleksiyonlarına binlerce kayıt eklendiğinde bu sorun ortaya çıkar. Batch Apex kullanımı genellikle bu tür senaryolar için önerilir çünkü asenkron işlemlerde heap limiti 12MB’a çıkar.
- CPU Time Limit Exceeded: Karmaşık hesaplamalar yapan, iç içe döngüler içeren veya verimsiz algoritma kullanan kodlar, transaction başına 10 saniye CPU zaman limitini aşabilir. Bu limit özellikle Formula field’ların değerlendirildiği veya Workflow kurallarının tetiklendiği senaryolarda daha kritik hale gelir.
- Total Number of Records Retrieved: Tek bir transaction’da toplam 50,000 kaydın üzerinde veri çekilemez. Büyük veri hacmiyle çalışan raporlama veya migration script’leri bu limitin farkında olmalıdır. Sayfalama yapısı kullanmak veya Batch Apex ile asenkron işleme geçmek çözüm yollarıdır.
Governor Limit Hatalarından Kaçınma Stratejileri
Salesforce Governor Limit aşımlarını önlemek için belirli kodlama kalıpları ve en iyi uygulamaları tatbik etmek şarttır.
Aşağıdaki stratejiler, production ortamında karşılaşılabilecek sorunları azaltabilir:
- Bulkification Prensibi: Apex kodunuz her zaman toplu operasyonları desteklemelidir. Döngü içinde SOQL veya DML kullanmak yerine, tüm kayıtları bir koleksiyonda toplayıp tek seferde işleyin. Salesforce platformu toplu operasyonlar için optimize edilmiştir ve bir List üzerinde yapılan tek DML işlemi, 10,000 kayıt içerse bile tek bir DML ifadesi olarak sayılır.
- SOQL Sorgu Optimizasyonu: Seçici SOQL sorguları yazın ve sadece ihtiyacınız olan alanları SELECT edin. Child relationship’leri kullanarak iç içe sorgular çalıştırın; bu sayede ayrı SOQL ifadelerine ihtiyaç duymadan ilişkili verileri tek sorguda çekebilirsiniz. WHERE ifadesinde indeksli alanlar kullanmak sorgu performansını önemli ölçüde artırır.
- Asenkron İşleme Kullanımı: Büyük veri hacmiyle çalışırken, Future methods, Batch Apex veya Queueable Apex gibi asenkron mekanizmaları tercih edin. Bu yöntemler daha yüksek Salesforce Governor Limit değerlerine sahiptir ve kullanıcı deneyimini olumsuz etkilemeden arka planda işlem yapmanızı sağlar. Batch Apex milyonlarca kayıt işlemek için ideal olabilir. Günde 250,000 (veya kullanıcı lisansı sayısının 200 katı, hangisi daha büyükse) asenkron transaction çalıştırabilirsiniz ve maksimum 5 batch job eşzamanlı olarak aktif olabilir.
- Limits Class ile İzleme: Apex kodunuzda Limits sınıfını kullanarak runtime’da kaynak tüketimini izleyin. Limits.getQueries() ve Limits.getLimitQueries() methodları ile kaç SOQL sorgusu kullandığınızı ve ne kadar marjiniz kaldığını kontrol edebilirsiniz. Proaktif izleme, limit aşımı olmadan önce alternatif stratejilere geçmenizi sağlar. Salesforce ayrıca governor limit kullanımının %50’sini aştığında e-posta uyarısı gönderecek şekilde yapılandırma imkanı sunar.
- Verimli Koleksiyon Kullanımı: Map ve Set koleksiyonlarını stratejik olarak kullanın. Map yapıları anahtar bazlı arama için ideal performans sunar ve iç içe döngüleri ortadan kaldırabilir. Bellek kullanımını optimize etmek için gereksiz alanları koleksiyonlarınıza eklemeyin ve işiniz bittiğinde büyük koleksiyonları temizleyin.
- Test Kapsamı ve Yük Testi: Birim testlerinizi toplu veri senaryolarını kapsayacak şekilde yazın. Salesforce Governor Limit’leri test etmek için Test.startTest() ve Test.stopTest() metotlarını kullanın; bu metodlar arasındaki kod ayrı bir Governor Limit bağlamında çalışır. Production ortamına geçmeden önce Sandbox’ta gerçekçi veri hacmiyle test yapmak önemlidir.
Salesforce Governor Limit Hakkında Sıkça Sorulan Sorular
Salesforce Governor Limit aşıldığında ne olur?
Salesforce Governor Limit aşıldığında platform anında işlemi durdurur ve işlenemeyen bir System.LimitException fırlatır. Bu exception yakalanmaz ve tüm transaction otomatik olarak geri alınır. Kullanıcı arayüzünde hata mesajı görüntülenir ve hiçbir veri değişikliği kaydedilmez. Production ortamında bu durum iş süreçlerinin durmasına neden olabilir, bu nedenle kod dağıtılmadan önce kapsamlı test yapılması önem taşır.
Salesforce Edition değiştirirsem Governor Limit’lerim artar mı?
Salesforce Edition değişikliği bazı limitleri etkiler ancak temel Apex Governor Limit’leri (SOQL 100, DML 150 gibi) değişmez. Edition yükseltmesi genellikle depolama kapasitesi, API çağrı limitleri, custom object sayısı ve e-posta gönderim limitlerini artırır. Professional Edition’dan Enterprise veya Unlimited Edition’a geçiş yaparsanız, daha fazla custom object oluşturabilir ve daha yüksek API limitlerinden faydalanırsınız ancak transaction başına SOQL ve DML limitleri sabit kalır.
Batch Apex kullanarak tüm Governor Limit’leri bypass edebilir miyim?
Batch Apex kullanımı bazı Salesforce Governor Limit’leri artırır ancak tümünü bypass etmez. Her batch çalıştırması için SOQL limiti 200’e, heap boyutu 12MB’a çıkar ve her batch bağımsız bir transaction olarak değerlendirilir. Ancak Batch Apex’in de kendine özgü limitleri vardır: günde maksimum 250,000 batch transaction çalıştırabilirsiniz, eşzamanlı batch job sayısı 5 ile sınırlıdır ve batch boyutu 2,000’i geçemez. Ayrıca Batch Apex içinde Future method çağıramazsınız.
Governor Limit hatası aldığımda kodu nasıl optimize edebilirim?
Governor Limit hatası aldığınızda ilk adım debug loglarını analiz etmektir. Hangi limitin aşıldığını tespit edin (SOQL, DML, Heap Size vb.) ve o alana odaklanın. Döngüler içinde SOQL veya DML varsa bunları döngü dışına çıkarın ve koleksiyonlar kullanın. Gereksiz SOQL sorguları varsa bunları birleştirin veya child relationship’ler ile tek sorguda çözün. Büyük veri hacim işlemlerinde asenkron mekanizmalara geçiş yapın. Kod yeniden yapılandırma sonrası mutlaka birim testlerle doğrulama yapın.
Production’da Governor Limit sorununu nasıl önlerim?
Production’da Salesforce Governor Limit sorunlarını önlemek için çok katmanlı yaklaşım gerekir. İlk olarak, sandbox’ta gerçekçi veri hacmiyle kapsamlı test yapın ve toplu veri senaryolarını kapsam altına alın. Dağıtım öncesi kod inceleme sürecinde Salesforce en iyi uygulamalarını kontrol edin. Production’da izleme ve uyarı mekanizmaları kurun; Setup Audit Trail ve Event Monitoring ile limit aşımlarını takip edin. Kritik süreçler için asenkron işleme tercih edin ve düzenli olarak kod optimizasyon incelemeleri gerçekleştirin. Ayrıca ekibinizi Governor Limit konusunda eğitin ve yaygın hatalar hakkında bilgilendirin.
Önceki yazımızı da ziyaret edin: “Salesforce Record Type Nedir?”
