ASP.NET uygulamalarında, web.config dosyası içerisinde yukardakine benzer bir satır göreceksiniz. ASP.NET 1.1'de "debug" parametresinin "default" değeri "true" iken, ASP.NET 2.0'da uygulamayı debug etmek istediğinizde size bu parametreyi tanımlamak isteyip istemediğinizi sorar. Sonuçta, geliştirme ortamından alınan hemen her web uygulamasında bu parametrenin değeri "true" olacaktır.
Geliştirme esnasında bu parametrenin değeri zaten "true" olmalıdır, çünkü zaten uygulamayı "debug" etmemiz gerekmektedir. Ancak, gerçek (production) ortamda bu parametre kesinlikle ve kesinlikle "false" olarak değiştirilmelidir. Gerçek ortama koyacağımız uygulamaların "debug" edilmesi zaten tamamlanmış, hatalardan arındırılmış olması gerekir. Genel olarak buraya kadar anlattıklarım herkese mantıklı görünse de, pek çok kişi bu parametrenin önemini göz ardı eder ve üzerinde durmaz. Dolayısıyla bize gelen çağrıların büyük kısmında gerçek ortamdaki uygulamaların "debug" modda çalıştığını görürüz.
Peki ama bu parametre ne kadar önemli olabilir? Gerçek ortamda "debug" modda çalışan bir uygulamada ne gibi sorunlarla karşılaşabiliriz?
Bu soruların cevabı, ASP.NET 1.1'den mi, 2.0'dan mı bahsettiğimize göre küçük farklılıklar gösterse de, ana hatlarıyla toparlamaya çalışacağım:
- Debug modda derlenen uygulamalarda pek çok optimizasyon yapılmayacaktır. Elbette bu da performans kaybına neden olacaktır.
- Debug modda derlenen uygulamalarda zaman aşımı değerleri (timeout) dikkate alınmaz. Bunun çok basit ve mantıklı bir nedeni vardır: Uygulama geliştirirken bazen kodun bir yerine "breakpoint" koyarız ve uygulama oraya geldiğinde dakikalarca kodu inceleriz. Biz bunu yaparken uygulamamızın zaman aşımı hatası alması pek de hoş olmazdı.
Zaman aşımı değerlerinin dikkate alınmaması, gerçek ortamlarda pek çok soruna neden olabilir. Örneğin, veritabanında yaşanan bir sorunun uygulamamızı tamamen çalışamaz hale getirmesi (deadlock) mümkün olabilecektir. - Çalışma esnasında fazladan bazı (debugging ile ilgili) bilgiler hafızada tutulacağından hafıza ve işlemci kullanımı çok daha yüksek olacaktır.
- Uygulamanın derlenme süresi çok daha uzun olacaktır. Bunun nedenı yine bir takım optimizasyonların yapılmayacak olmasıdır.
Yukarıda bahsettiklerimi kaba bir özet olarak düşünebilirsiniz. Internet üzerinde çok daha detaylı çok sayıda makale bulabilirsiniz bu konuyla ilgili.
ÇÖZÜM:
Gerçek ortama taşınan her uygulamanın web.config dosyasını kontrol edin. Bu parametrenin gücünü hafife almayın.
ASP.NET 2.0'la beraber, bu anlamda işimizi çok kolaylaştıran bir parametremiz oldu: "retail". Machine.config içerisine ekleyebileceğiniz bu parametre ile, o makinede çalışan tüm web uygulamalarını, web.config'lerinde ne yazarsa yazsın, "release" moda almış olursunuz:
<configuration>
<system.web>
<deployment retail="true"/>
</system.web>
</configuration>
"retail" parametresi başka şeyler de yapar ama bunların detaylarına burada girmeyeceğim.
CENK ISCAN
EK 1: Seneler önce bunlarla ilgili yazdığım bir yazıyı buldum. Yazıda .Net 1.x'ten bahsediliyor (o zamanlar henüz 2.0 yoktu) ama aynı şeyler 2.0 için de geçerlidir:
Yüksek performanslı ASP.NET uygulamaları için yapılması gerekenler
https://support.microsoft.com/gp/aspnet_performans/tr/
EK 2: "retail" parametresi debug modu kapatır ancak eğer web.config'de debug="true" yazıyorsa, zaman aşımı değerleri yine de dikkate alınmaz. İsteklerin zaman aşımına uğrayabilmeleri için mutlaka web.config'den debug mod kapatılmalıdır.