Performans Yönetimi

Sistemin sağlıklı çalışabilmesi için aşağıdaki kriterler dikkatli bir şekilde incelenmeli, ihtiyaç durumunda uygulanmalıdır.

Donanım ihtiyacı belirlenirken şu ölçütleri göz önünde bulundurmak gerekir;

1. Content Server ve SQL Server'ın farklı makinelerde olması performans için önemlidir. 200 ve üstü kullanıcılarda ayrı sunucular olması tavsiye edilir.
2. Eğer birden fazla Content Server kurulacak ise her birinin ihtiyacı aynıdır.
3. Eğer SSL sertifika kullanılacak ise Core ve RAM miktarı %50 artırılmalıdır. İhtiyaçlar bölümünde SSL sertifikasının olduğu durum verilmiştir.
4. Eğer Mobil erişim sağlanacak ise mutlaka SSL kullanılmalıdır.
5. Eğer dış erişim yoğun ise, entegrasyon ile yoğun belge arşivleniyor ise ek Content Server kurmak doğru yaklaşımdır. Dahili kullanıcıların birinci sunucuya, diğer entegrasyon ve dış kullanıcıların ikinci sunucuya erişimi tavsiye edilir.
6. Eğer aktif kullanıcı sayısı 500 ve üstü ise birden fazla Content Server kullanılması tavsiye edilir.
7. Veri tabanı mevcut bir sunucu üzerinde konumlandırılabilir. Kurulum yapılacak ortamda SQL Server için belirtilen ihtiyaçlara mutlaka uyulmalıdır.
8. Belge arşivinin saklanacağı disk için plan yaparken bir belgenin ortalama 300 Kb boyutunda olacağı hesaplanır. Buna göre 1 yıl veya 3 yıllık tahmini belge adedi hesabı ile ihtiyaç duyulan disk miktarı hesaplanabilir. Eğer hiçbir hesap yapılamıyor ise 200 GB disk alanı ayırmak mantıklıdır. Doluluk oranı belli periyotlar ile gözlemlenmeli, doluluk oranı %80 civarına geliyor ise disk artırımı yapılmalıdır.
9. Veri tabanı disk ihtiyacı tahmini belge ve akış adedine göre hesaplanır. Belge başına 20Kb, akış başına 10 KB hesaplamak uygundur. Eğer hesaplama yapılamıyor ise 200 GB disk alanı ayırmak mantıklıdır. Doluluk oranı belli periyotlar ile gözlemlenmeli, doluluk oranı %80 civarına geliyor ise disk artırımı yapılmalıdır. 
10. Index Server birden fazla kurulabilir. Bu durumda her biri için aynı donanım kullanılmalıdır.
11. WorkFlow Server iş akışları ile tüm işlemleri yapan servisin adıdır. Bu servis de birden fazla kurulabilir. Kaynak ihtiyacı her ne kadar akışların boyutlarından da eklense de genel hesap olarak günde başlayan her 2000 adet için bir adet servis kurmak uygundur. 
12. Web Servis çağrıları: Sistemde yapılan tüm servis çağrıları Content Server tarafından ilgili servis adresine doğru yapılır. Elektronik formlardaki servis çağrıları da Content Server tarafından yapılır. Bu durumda servisin kendi içindeki performans sayılmaz ise network üzerinden alınan/verilen verinin boyutu devreye girer. Aynı durum SAP, Logo gibi konnektör katmanı için de geçerlidir. Burada iyileştirme için tavsiye edilen “Retrieve as needed” prensibinin uygulanmasıdır. Örneğin SAP den bir listenin alınarak elektronik formlarda kullanıldığını ve bu listenin nadiren değiştiğini düşünelim. Aşağıdaki gibi bir yapı kurularak her seferinde SAP servis işlemi ortadan kaldırılabilir;

1. PaperWork üzerinde sabit bir liste oluşturulur.
2. Günlük belli periyotlar ile SAP den asıl listeyi alan ve PaperWork listesini güncelleyen bir metod geliştirilir.
3. Elektronik formlarda sabit liste kullanılır.
4. Eğer zaman zaman kullanıcının listenin güncel halini kullanması zorunlu ise elektronik formda bir tuş ile metod tetiklenerek listenin güncellenmesi sağlanabilir.
5. Bu durumda her seferinde SAP den çağrı yapılması yerine elektronik formlar sadece PaperWork sabit listelerini kullanır. Her durumda sabit listeyi kullanan elektronik formun açılması daha kısa sürelidir. Diğer yandan SAP ye giden çağrı miktarları düşürülerek ilgili sistemin de daha sağlıklı çalışması sağlanmış olur.
6. Aynı şekilde dış sistemlere veri gönderilmesi gibi işlemlerde de metod kullanılabilir. Çalışma saatleri haricinde oluşan veri ilgili sisteme bir metod yardımı ile gönderilebilir. Buradaki amaç kullanımın yoğun olduğu saatlerin dışında entegrasyonların çalışmasını sağlamaktır.

• Arşivlenmiş belge miktarlarında çeşitli bariyerler vardır. 1,5,10 ve 50 milyon belge miktarlarında CPU/RAM kullanımı incelenmelidir.
• Belgelerin okuma yazma işlemleri esnasında I/O zamanları incelenmelidir. Belgelerin Network saklama birimlerinde olması, nispeten yavaş diskler üzerinde bulunması bir performans konusudur.
• Kullanıcı sayıları için aynı şekilde bariyerler vardır. 300,400,500 aktif kullanıcı (sisteme giriş yapmış) bariyerlerinde CPU/RAM kullanımı incelenmelidir.
• Entegrasyon miktarları ve yoğunluğu bir performans konusudur. Yoğun zamanlarda 1 dakika içinde 300-500 arası belge arşivlenmesi, 100 civarı iş akışının başlatılması durumunda CPU/RAM kullanımı incelenmelidir.
• Index Server, arşivlenen belgeler üzerinde OCR işlemi yapar. OCR esnasında, matematiksel işlemler yapıldığı için çalışma esnasında %70-90 CPU kullanır ve normaldir.

Ayrıca sistemin yatay büyüyebildiği unutulmamalıdır. Sisteminizde performans düşüklüğü hissediyorsanız aşağıdaki çalışmaların bazılarını uygulayarak sistemin sağlıklı çalışmasını sağlayabilirsiniz.

1. Content Server yükünü dengelemek adına birden fazla kurulabilir. Eğer sistemde işlem yapan kullanıcı miktarı 400-500 civarına geliyor ise tavsiye edilen en az 2 Content Server kurulumu yapmaktır.
2. Eğer Content Server CPU tüketimi %50’leri anlık da olsa uzun süreli geçiyor ise yük dengeleme amacı ile 2nci sunucuyu hayata geçirme zamanı gelmiştir. Bu genelde sisteme yoğun atılan belge durumunda gerçekleşir. 2nci bir Content Server kurulumu ile sisteme toplu atılan belgelerin 2nci sunucu üzerinden arşivlenmesi sağlanabilir.
3. WorkFlow servisi kendi veri tabanına sahiptir. Bu veri tabanında akışlar ilk başladığında izlerini tutarlar. Akış sona erdiğinde buradan silinirler. Bu nedenle ilk etapta büyüyen, aktif akış adedi kadar kayıt olan, daha sonra büyümeyen bir veri tabanıdır. Bu veri tabanı Transaction süreleri uzun ve yoğundur. İlk kurulum olarak PaperWork veri tabanı ile aynı sunucuya kurulurlar. Yoğun çalıştığı durumlarda PaperWork veri tabanı performansını da etkilerler. WorkFlow veri tabanı ücretsiz olan MS SQL Express versiyonu üzerinde de çalışabilir. Eğer SQL Server kaynaklarınızı fazla tüketiyor ise bu veri tabanı Content Server makinesine taşınarak veri tabanı rahatlatılabilir.
4. WorkFlow servisi yük dengelemesi yaparak çalışabilmektedir. Eğer günlük başlayan akış adetleri 1500-2000 arasına çıkıyor ise yük dengelemesi yapmak ve veri tabanlarını SQL Server dan ayırmak doğru yaklaşımdır. Burada aslında önemli olan akış adedi değil, bir akıştaki otomatik aktivite sayısıdır. Otomatik aktivite sayısı ne kadar çok artar ise WorkFlow veri tabanı o kadar yoğun işlem yapar.
5. Tüm sistemin en zayıf noktası MS SQL Server katmanıdır. İşlem adetleri, Aktif kullanıcı sayıları, birikmiş belge miktarı, birikmiş akış miktarı ne kadar çok olursa sistem performansı o kadar çok etkilenir. PaperWork veri tabanı son derece optimize çalışır. En yoğun dönemlerinde bile Query Execution zamanları 500 milisaniyeyi geçmez. Bu nedenle hızlı bir disk üzerinde veri tabanı dosyalarını konumlandırmak, gerekli RAM ve CPU‘yu sağlamak performansı kontrol altına almak için yapılması gerekli ilk çalışmadır.
6. PaperWork veri tabanı üzerinde periyodik bakımlarını kendisi yapar. Her hafta Cumartesi gece yarısı çalışan Tanımlı bir iş yardımı ile tüm indeksler otomatik olarak defrag edilir. Tüm veri tabanı istatistikleri otomatik olarak güncellenir. Kendi içinde tüm sistem tablolarının bakımları otomatik olarak yapılır. Burada dikkat edilmesi gereken sistemde yeni oluşturulan Tip tanımlarıdır. Tip tanımları sadece PRIMARY KEY ile sistemde oluşur. İhtiyaç durumunda tip üzerinde yaptığınız işleme göre gerekli indeksler müşteri tarafından oluşturulmalıdır. Örneğin arşivde bir tip tanımlayarak belge arşivlediğinizi, miktarın 1 milyon civarında olduğunu düşünelim. Bu tipin herhangi bir alanı üzerinden arama yapıyorsanız arama performansınız düşmeye başlar. Bu durumda ilgili tablo üzerinde 2nci, 3ncü indeksleri oluşturmanız gerekir. Yani kullanım şekline göre performans artırıcı önlemler alınmalıdır.

Aşağıda çok yoğun işlem yapılan bir sunucu ve metrikleri verilmiştir;

1. Sistemde 150 milyon birikmiş belge bulunmaktadır ve boyutu yaklaşık 7Tb. civarındadır. Her belge için ortalama 10 indeks alanı kullanılmıştır ve toplam 15 belge tipi bulunur.
2. Çalışıp bitmiş 15 milyon akış bulunmaktadır. Toplam 5 değişik akış bulunur ve her akışta ortalama 100 aktivite bulunur.
3. Sistemde tanımlı 15.000 kullanıcı bulunur. Yoğun testlerde 1000 civarı kullanıcı aktif olur.
4. Yük testi 4 değişik sunucu üzerinde çalışan 20 değişik uygulamadan belge arşivleme ve akış başlatma olarak yapılmıştır. Bu sunucularda 2 Core ve 4Gb. RAM bulunur.
5. 1 dakika içinde ortalama 5.000 adet yeni belge arşivlenmiştir.
6. 1 dakika içinde ortalama 100 yeni iş akışı başlatılmıştır.
7. Testler esnasında 2 adet Content Server yük dengeli olarak kullanılmıştır. Her biri 8 Core ve 8 Gb. RAM kullanır. Windows 2019 Standart 64 bit işletim sistemi kullanılmıştır.
8. Sistemde 4 adet WorkFlow servisi kullanılmıştır. Bu servislerin her birinin veri tabanı kendi üzerinde bulunur. 2 Tanesi Content Server ile aynı sunucuda, 2 tanesi ise 4 Core, 4RAM kaynaklı sunucular üzerinde çalıştırılmıştır.
9. MS SQL Server 2019 Standart, 64 bit versiyonu kullanılmıştır. İşletim Sistemi 64 bit Windows 2019 Standart ‘dır. Toplam veri tabanı boyutu 750 Gb civarındadır. Sunucu üzerinde 16 Core ve 64Gb RAM bulunmaktadır.
10. Yapılan tüm işlemler 2 gün devam ettirilmiş ve herhangi bir problem yaşanmamıştır.

ISDD ™ Servisi Kaynak Tüketimi

Index Server üzerinde tam metin arama motoru ve OCR işlemleri yapılır. Eğer ISDD™ lisansı aktif ise bu sunucu üzerinde PaperWork yapay zeka motoru çalışır. Normalde yapay zeka motoru GPU üzerinde çalışabilir. Eğer GPU kullanılıyor ise 8 Core yeterlidir. Eğer CPU kullanılacak ise 16 Core kullanılması tavsiye edilir. 

ISDD™ modülünün olduğu durumda kullanılan core miktarı ile çalışacak uygulama adedi parametreler ekranından belirlenmelidir. Bu işlem için ISDD_QUEUE_SIZE parametresi kullanılır. Core-6 olarak ayarlanması uygundur.