Merhaba,

Geliştirdiginiz bir web uygulamasının yavaşlıgının nerden kaynaklandıgını anlamak için nasıl bir yol izlersiniz yada aklınıza nereleri ne şekilde kontrol etmek gelir?

Yavaşlıgın uygulamadan mı, networkten mi, app serverdan mı, veritabanından mı ... kaynaklandıgını nasıl ölçersiniz?

Network, Database, ve App server da ne şekilde test ve stres testleri yapıyor hangi toolları kullanıyorsunuz?

soruldu: 01 Kas '13, 14:57

Alp's gravatar image

Alp
873304447
cevap kabul oranı: 18%

değiştirildi: 04 Kas '13, 01:47


Değişik senaryolar olabilir, benim uyguladığım yöntem çoğunlukla : Öncelikli olarak veritabanı ve app sunucunun işlemci, ram ve disk kullanım durumuna bakarım sorun veritabanında mı yoksa app sunucuda mı diye.

Eğer bunlarda bir problem yoksa o zaman network durumu, clientların işlemci, ram ve ekran kartı durumu vb donanımsal sorunlara bakarım.

Eğer veritabanında bir problem varsa veritabanı uzmanına haber veririm :) Bir veritabanı uzmanımız yoksa o zaman veritabanı üzerinde o anda çalışan sorgulara bakıp hangi sorgular index kullanmıyor hangi sorgular gereksiz kayıt çekiyor gibi durumlara bakarım. Bu şekilde sorguları optimize ederim.

Eğer app sunucu tarafında bir problem varsa iş daha karışık bir hal alır çünki onun performansı çoğunlukla bizle alakalı oluyor. Bu durumda önce log durumuna bakmak lazım, sonra jvisualvm ile java process bilgilerine bakmak lazım. Kaç tane thread çalışıyor, ram kullanan şeyler neler, gc durumu ne? Daha sonra sampler tabına geçip oradan cpu buttonu ile hengi metod ne kadar zaman harcıyor diye bir süre (bazen günlerce) onu izlerim. Fazla ram tüketimi varsa monitor tabından bir heap dump alırım ve eclipse ile heap içerisinde tam olarak neler var ona bakarım....

Şimdi bazılarınız diyebilir niye profiler açıp incelemiyorsun ? Büyük bir proje üzerinde profiler çalıştırmak imkansız gibi birşey, hatta production ortamında çalıştırmanıza kimse izin vermez. Benim önerilerim production performansını nerdedeyse !! hiç düşürmeden yapılabilecek şeyler. jvisualvm üzerinde de profiler var ama mümkün olduğunca çalıştırmamak lazım :)

Not: jvisualvm olmayan komut satırı ortamlarında killall -3 java komutu ile tüm thread lerin stack durumunu loglara döküp inceleyebilirsiniz.

permanent link

cevaplandı: 02 Kas '13, 01:25

myururdurmaz's gravatar image

myururdurmaz
2.2k11027
cevap kabul oranı: 23%

"Eğer sayfalara fazla veri getiriyorsanız bu client'tan db'ye kadar giden bir yoldur ve ne kadar çok ara katman ve framework varsa o kadarda uzun bir yoldur. Burada makul çözüm memcached yada hazelcast gibi cache teknolojileridir."

permanent link

cevaplandı: 02 Kas '13, 08:33

Turgay%20Can's gravatar image

Turgay Can
8.4k63799
cevap kabul oranı: 18%

Merhaba cevabınız için teşekkürler güzel bir çözümleme ama burda sadece yazılım geliştirme tarafıyla ilgili bir problemi ele almışsınız. Şöyle düşünebiliriz. Yazılımınız mevcutta kullanılıyordu yeni bir versiyon çıktınız, yeni bir servera geçtiniz, belkide aynı zamanda network altyapınız degişti (zor bir seneryo oldu farkındayım :) ) Genel bir çerceveden bakarsanız nasıl hareket edersiniz.

(02 Kas '13, 08:48) Alp Alp's gravatar image

O kadar genele hakim değilim. Sonuçta App -> App Server -> DB -> Network(Backbone) -> Sistem(Alt yapı) ap ayrı dünyalar her ne kadar beraber kullanılsalarda. Eğer elinizde eski çalışan sisteme dair metrikler varsa, bu hiyerarşide incelenebilir.

(02 Kas '13, 09:07) Turgay Can Turgay%20Can's gravatar image
Cevabınız
toggle preview

Bu soruyu takip et

E-Posta üzerinden:

Üyelik girişi yaptıktan sonra abonelik işlemlerini yapabilirsiniz

RSS üzerinden:

Cevaplar

Cevaplar ve Yorumlar

Yazı Formatlama

  • *italic* ya da _italic_
  • **bold** ya da __bold__
  • link:[text](http://url.com/ "başlık")
  • resim?![alt text](/path/img.jpg "başlık")
  • liste: 1. Foo 2. Bar
  • temel HTML etiketleri de kullanılabilir

Bu sorunun etiketleri:

×1,079
×90

Soruldu: 01 Kas '13, 14:57

Görüntüleme: 630 kez

Son güncelleme: 04 Kas '13, 01:47

powered by BitNami OSQA