delphiden veri bağlantı yöntemi hakkında

[adelphiforumz]

S.A.

Aşağıdaki gibi bir yapıyı sizce nasıl çözmeliyim.

30 ayrı lokasyondan toplam 250 client makina var ve her makina üzerine kurulu local programlar çalışıyor
bunlar bir vpd ağı ile ADO connection yöntemi ile bağlantı kuruyor. Merkezde tekbir sql server mevcut

sizce sql server üzerinde farklı portlardan bağlantı yapmak yada tek bir porttan bağlantı yapmak birşeyi değiştirirmi
yada bu işlemde performansı artırmak için ne yapmak gerekir.

Teşekkürler

[mrmarman]

INDEX INDEX INDEX

- Sektör, veritabanı içeriği vs. ayır bir konu ama INDEX'leri doğru kurduğun sürece diğerleri tali kalıyor.

[adelphiforumz]

S.A

Kullandığım sistemde yaklaşık 150 ye yakın tablo ve her tablonun bir primery keyi ayrıca en çok kullanılan alanlar index yapısında
indexler mümkün olduğunca numeric alanlar ve tarihler üzerinden yapılandırıldı.
tüm dosyaların birbirlerine erişimleri primery key ve diğer dosyaların indexleri üzerinden bağıntılı

Sistemde tüm sorgulamalar StoreProcedure yapısıyla kullanılıyor ayrıca insert, update, delete işlemleride yine aynı şekilde StoreProcedurler ile yapılıyor
yani delphi içerisinde neredeyse hiç sql cümlesi yok gibi bir şey, çok sık kullanılan yapılar function-table yada function-scaler ile alınıyor
mümkün olduğunca iç içe sorgular StoreProcedurler içerisinde kullanılmıyor kulanıcının ekranlarındaki filtreleme alanları çoğunlukla indexler üzerinden yapılıyor

problemin başlangıcı ise sql üzerinde hiç bir şey çalıştırılmasa bile yaklaşık 200 kullanıcı sql'e connection yaptığında
bu kullanıcılardan 5-10 tanesi sorgu yapınca cevap süreleri inanılmaz uzuyor.

bunun nedenini bulmaya çalışıyorum

teşekkürler

[mrmarman]

Diğer kullanıcılar hızlı, bir kaç tanesi yavaş diyorsanız ilin rengi değişiyor, ağ sağlığı giriyor. Aynı şartlarda sorgular arasında uçurum varsa diye cevap verdim.

Wifi ile bağlantılı olanların wifi çekim gücü, aynı kanaldaki başka bağlantıların wifi dalgalanması yaratmadı, güvenlik ve password durumu bile etki eder mesela.

Index mevzuuna dönersek de yapılan ağırlıklı sorgulara göre indexlerin kurulması lazım geliyor.

Basit bir örnek vericem, sonucu çok değiştirmiyor ama örnektir yine de; indexler küçükten büyüğe yani asc dizayn edilmiş iken sorgular büyükten küçüğe, son bilmemne kayıt vs ise de doğru kurulum yapılmış sayılmaz. İfadem yeterince açık mı bikemedim umarım anlatabilmişimdir.

Yavaş sonuç dönüyor dediğiniz bir sorgu seçin, önce sorguya ilişkin tablolardaki indexleri kaldırın, sorguda geçen where ifadesi ve order by durumu öncelikli bir kaç denemeler yapın. Projenizi değiştirmenize lüzum yok, direkt Database manager ne kullanıyorsanız oradan test edin. Zaten hepsi dönen sonuç için me kadar süre tuttuğunu bildiriyor. Karşılaştırmalı test etmiş olursunuz.

[thelvaci]

Sql Server üzerinde performans ile ilgili bir çok ayarlama yapılabilir. 250 client bağlantısı Sql Server için hiç denecek kadar azdır. Sql Server bu bağlantıları son derece rahat yönetebilir. Ancak 5-10 client'ın hemen hemen aynı zaman dilimlerinde aldığı sorgular ile sistemin yavaşladığını söylediğinizde; sorguların veritabanı nesneleri üzerinde Lock'lar oluşturduğunu dolayısı ile beklemelere neden olduğunu düşündüm. Pek tavsiye etmesem de, table hintlerinden READPAST ve NOLOCK'a bakmanızı öneririm ilk aşamada. Ama bunları kullanmanızı önermem. Sadece locking ile alakalı fikir edinmeniz için gereken başlangıç noktası olarak vermek istedim. Esas olarak bakmak isteyeceğiniz şey ise transaction isolation seviyeleri. Bunun için yine bu forumda vermiş olduğum bir cevabı da incelemeniz faydanıza olacaktır.

viewtopic.php?f=27&t=31938

Aynı zamanda, tüm tablolarınızda bir primark key bulundurmanız son derece faydalı olacaktır. Bu sayede "heap" denilen index'siz tablolardan kurtulmuş olursunuz. Ancak şunu da ifade etmek gerekir, çok sık değişen tablolar üzerinde fazla index tanımlamak da performansa ciddi anlamda kötü etki edecektir. Çünkü tanımladığınız index'ler verinin fiziksel olarak yer değiştirmesine neden olabileceği gibi, çok fazla index tanımlamak non-clustered index leaf'lerinin erişim algoritması nedeni ile yavaşlamaya neden olabilir. Bunun dışında, tempdb veritabanınızın boyutunu makinanızdaki CPU sayısı ile orantılı olacak şekilde bir kaç adet dosyadan oluşturabilir, hatta bu dosyaları fiziksel olarak başka disklere konumlandırabilirsiniz. Aynı zamanda SQL Server'ın T1118 trace flag'ını açarak temp db dosyalarının eşit boyutlarda büyümesini sağlayabilirsiniz. Tabii yapacağınız ayarlar sadece tempdb'de değil kendi veritabanınızda da olmalı. Aynı şekilde, varsayılan olarak belirtilmiş olan 1 mb. lık auto growth ayarını daha yüksek bir değere çekmelisiniz. Data dosyalarınız için 512 mb, Log dosyalarınız için de 256 mb. gibi. Aynı zamanda, SQL Server'ın genel ayarlarından SQL Server'ın kullanacağı maximum memory'i sistem memory'sinin %70 leri civarına ayarlamalısınız. Ve tabii veritabanlarının kullanmadığı bir zaman diliminde çalıştırılmak üzere, bir veritabanı bakım planı hazırlamalısınız. Bu bakım planı içinde, elbette Rebuild index ve istatistikler olmalı. İstatistiklerin güncellenmesi veritabanı performansı açısından inanılmaz derecede önemlidir. Güncel istatistikler sayesinde Sql Server Query Optimizer doğru execution planlar üretebilir.

Son olarak snapshot transaction isolation seviyesine bakmanızı şiddetle tavsiye ederim.

[adelphiforumz]

tuğrul hocam çok teşekkürler

[csunguray]

Doğrudan ADO bağlantısı kurmak yerine uygulamanızı servis tabanlı veya çok katmanlı bir yapıya geçirmeniz ciddi performans artışı sağlayacaktır. Bunun için DataSnap kullanabilirsiniz.

[ulutepe]

Doğrudan ADO bağlantısı kurmak yerine uygulamanızı servis tabanlı veya çok katmanlı bir yapıya geçirmeniz ciddi performans artışı sağlayacaktır. Bunun için DataSnap kullanabilirsiniz.

Arkadaşım doğru söylüyor. 250 terminali direk veritabanına bağlıyorsan hele bide sql server express kullanıyorsan hayatta verim alamazsın. Hele birde kullanıcılar yüksek kayıt sayılı datasetler çekiyorlarsa hem sunucun hem terminallerin yığılır kalır termianllerin yada sunucunun bant genişliğinden bahsetmiyorum bile. Bu nedenledir ki yüksek terminal sayılı sistemlerde 2 katmanlı(server-client) kullanmak her zaman için sonun başlangıcı demektir.

Yapılması gereken terminalle ile sunucular arasına bir iş katmanı koymak ve bu iş katmanın threat pooling desteği ile donatarak TCP yada UDP üzerinden terminallere XML yada JSON olarak veriyi göndermek. Datasnap bir çözüm olsa'da bazı persformans sıkıntıları nedeniyle ilerleyen zamanlarda seni canından bezdirebilir(XE2 ten sonra datasnap'ı inceleme fırsatım olmadı o nedenle XE2 'e kadarki performansını değerlendirdim). Indy ve Jedi(JCL) bileşenleri ile kendi iş katmanını dizayn edebilirsin hemde threat pooling desteğide ekleyebilirsin. Bunu yapman demek tüm yazılımını baştan aşağı değiştirmen anlamına geliyor. bu kadar terminal sayısına ulaştıktan sonra işin oldukça zor olacak gibi. Kolay gelsin