"Küçük Veri" TuzağıKafayı yiyecektim. Geliştirme ortamında, test veri setiyle çalışırken her şey mükemmeldi. 1000 satırlık bir CSV, birkaç saniyede işleniyordu. "Bunun için kompleks bir algoritma yazmaya ne gerek var, for loop gayet güzel çalışıyor" diye düşünmüştüm. Meğerse kendi mezarımı kazıyormuşum.
Production'da İlk ÇöküşCanlıya aldık. İlk gün, sistem gül gibi çalışıyordu. İkinci gün, kullanıcı sayısı biraz arttı. Üçüncü günün sabahı, monitoring alarmları deli gibi ötmeye başladı. CPU %99'a tırmandı, response süreleri saniyeleri aştı. Hemen loglara daldım.
Sorun, o masum gördüğüm veri işleme scriptindeydi. Geliştirmede 1000 satırla test ettiğim yer, production'da günde 500.000 satır işliyordu. O basit for loop içinde, her iterasyonda bir dosyayı açıp kapatıyordum. I/O operation'lar katlanarak artmıştı.
Python:
# Kötü Fikir: Her döngüde dosya işlemi
for item in data_list:
with open('log.txt', 'a') as f: # BU PATLAR!
f.write(f"Processed {item}")
Debug ve İsyankar ÇözümStackOverflow'da bile tam benim durumumu anlatan bir şey bulamadım. Profiler'ı çalıştırdım ve gördüğüm manzara şaka gibiydi. En basit optimizasyonları bile atlamışım. Hemen kodu baştan yazdım. Dosya işlemlerini loop dışına aldım, gereksiz list comprehension'ları temizledim, bellek kullanımını düşürmek için generator'lara geçtim.
Python:
# Daha İyi: I/O'yu minimize et
with open('log.txt', 'a') as f:
for item in data_list:
f.write(f"Processed {item}\\n")
Alınan Acı DersOlay şu: Geliştirme ortamında "küçük" olan her şey, production'da mutlaka büyür. Kullanıcı sayısı artar, veri çoğalır. O "şimdilik idare eder" dediğin nested loop, O(n²) karmaşıklığıyla geri dönüp seni bulur.
Şimdi prensip edindim: Test verimi, production'daki beklenen boyutun en az 10 katı yapıyorum. "Optimize etmeye gerek yok" cümlesini sanal bir post-it'e yazıp monitörüme yapıştırdım.
Siz de böyle "küçük" sandığınız bir şey canlıda başınıza büyük işler açtı mı? Bu tür performans tuzaklarını erkenden yakalamak için neler yapıyorsunuz?