Kategori: <span>Bilgisayar</span>

Merhabalar, Sizin başınıza gelebilir dikkatli olun. 2009’dan beri hiç sorunsuz kullandığım firma bir anda nasıl değiştiğini ben de anlamadım. Önce 14.10 tarihinde uydurma bir kampanya tanımladılar. Bir sürü telefon, bin…

Bilgisayar

Bilgisayar

Merhabalar, Ruby üzerinde 1.9 sürümlerinin yeni versiyonu 1.9.3 karşımızda. Bu versiyon ile beraber Özellikle “garbage collector” üzerinde bir takım iyileştirmeler yapılmış. Bununla beraber Change Log adresinde Özellikle thread sınıfı için…

Bilgisayar

Merhabalar,

Bir Önceki yazımızda rails için jruby kullanımından ve windows üzerinde rails uygulamalarının servis edilmesi hakkında bir yazı yazmıştık. Bu yazıda jetty_rails’in sürümünün biraz eski olduğundan (son güncelleme tarihi 2009-07-08 20:28) bazı problemle karşılaştığımı yazmıştım.

Bu yazıda sizlere bu problemleri nasıl ortadan kaldıracağımızı anlatmak istiyorum.

1. Öncelikle jetty-rails’i standart gem yÖntemleriyle yüklüyoruz.

jruby -S gem install jetty-rails

Bilgisayar Ruby (Ruby on Rails)

Merhabalar, Ne zamandır arkadaşlarım rails için yazılım geliştirme ortamı sorup duruyorlar, aslında ortada çok fazla alternatif olduğu için kafa karışıklığına neden olabiliyor. Son (bir windows sunucu da host etmek zorunda…

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Geçenlerde Oracle 11g’de üç çeşit cursor’ın karşılaştırmalı performans sınamasını gerçekleştirdim. Aslında iş için gerekti ama fırsattan istifade sizlerle de paylaşmak istedim. Bu aralar aktif şekilde blog yazımı ile ilgilenmesem de buna benzer fırsatları değerlendirmek gerekli :)

3,629,848 adet kayıt için 11g’de performans değerleri aşağıdaki gibidir;

1- Cursor ve Bulk Collect (Open / Fetch Bulk limit 10000 / Close) ~2,5sn – belirlenmiş memory kullanımı.
Start:34.26.163863000 PM +03:00
End: 34.28.616085000 PM +03:00

2- Sadece Implicit (For) Cursor ~4,5sn – düşük memory kullanımı (1. maddenin limit 100 ile kullanımı kadar)
Start: 33.22.212231000 PM +03:00
End: 33.26.701057000 PM +03:00

3- Eski tarz (Open / Fetch / Close) Cursor ~50sn – çok düşük memory kullanımı
Start: 27.52.405369000 PM +03:00
End: 28.42.254359000 PM +03:00

1. madde ile 2. madde arasındaki fark tamamen “limit 10000” den kaynaklanıyor. 2. Madde için oracle sistemi varsayılan olarak 100 değerini kullanıyor. Bu nedenle 2.nin memory kullanımı 1.ye gÖre daha az olduğu yÖnünde genel bir kabul mevcut.

Kolay gelsin.

Bilgisayar

Merhabalar,

Birkaç arkadaşım yazıları okuduktan sonra Kyoto Cabinet’in sorgu performansını merak etmiş. Bunun üzerine küçük bir çalışma ile sorgulama performanslarını sizlerle paylaşmak isterim.

Hemen sonuçları yazmakta fayda gÖrüyorum :)

MySQL üzerinden daha Önceki yazılarımda yer alan konfigurasyon ile (engine: Innodb, primary key üzerinden sorgulama yapılıyor.) 100 thread ile 1.000.000 kayit 48.56 sn’de sorgulanmıştır.

KyotoCabinet üzerinden daha Önceki yazılarımda yer alan konfigurasyon ile (engine: Hash, ek parametreler DB::OCREATE | DB::GCONCURRENT ve key üzerinden sorgulama yapılmıştır) 100 thread ile 1.000.000 kayit 4.54 sn’de sorgulanmıştır.

Şaka değil gerçek.

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Bir KyotoCabinet yazısına daha hoşgeldiniz. Bugün sizlerle MySql’in 100 thread üzerinden “insert” yetenekleri ile kyoto cabinet’inkileri birbirleriyle karşılaştıracağız. Peki bunu neden yapıyoruz, çünkü bir Önceki yazımızda tek thread üzerinden kyoto cabinet üzerine veri yazma işlemi mysql’a gÖre ~10 kat daha hızlı olduğunu gÖrdük.

Bu durum, tüm transactional tablolarımızı kyoto cabinet’e taşımamıza neden olmasa bile, yazılım geliştirirken kullandığımız bir çok “log” tablolarını taşımamızın kapısını aralar diye düşünüyorum. Yazılım geliştirirken bu kayıtları için bir log tablosuna veya dosyaya yazarız. Fakat dosyaya attığımız kayıtları tekrar okumak veya istediğimiz kayıda erişmek istediğimizde problemlerle karşılaştığımız için genelde “log” tablolarını tercih ederiz. İşte bu tercihlerimizde, eğer bu testten de başarı ile geçerse, log işlemleri için (hatta belki daha fazlası için) mysql yerine kullanılabilir.

Veya tecrübe ile sabit, web sistemlerinin session yÖnetimi ve loglaması için kullanılabilir. Aklınıza bir soru gelebilir, çünkü session tablosunda sorgu atmak için kullandığımız tek alan SessionId’dir. Yani ID üzerinden yapacağımız tüm işlemlerde bu veri tabanı yapılarının klasik veri tabanı yapılarına gÖre çok daha hızlı olduğunu unutmayalım.

Bilgisayar Ruby (Ruby on Rails)

Merhabalar,

Bir Önceki yazımızda Ruby üzerinden KyotoCabinet’e 1.000.000 (1 milyon) veri girişini çok kısa bir sürede tamamlamıştık. Daha sonra içime bir kurt düştü, acaba mysql’de durum nasıldı? Yani aynı koşullar altında mysql veri tabanına 1.000.000 kayıdı kaç sn içerisinde yazabilecektim?

Makinanın Özelliklerini bir Önceki yazımızda vermiştim.

Bu işlemin testi için Öncelikle kendimize oldukça hızlı olduğuna inandığım, KyotoCabinet’in Ruby arabiriminde olduğu gibi C dili ile yazılmış MySQL/Ruby bir arabirim kütüphanesi buldum ve 2.8.2 versiyonunu kurdum. Bununla beraber MySQLClient versiyonunun 5.1.41 olduğunu sÖylemeliyim.

Daha sonra key, value tutacağımız bir veri tabanı oluşturdum. Öncelikle MyISAM motorunu kullanan bir tablo oluşturdum ve testlerimi bu tablo üzerinde yaptım.

CREATE TABLE `kyoto_cabinet`.`simple_table` (
  `key` CHAR(12) UNICODE NOT NULL,
  `value` CHAR(12) UNICODE NOT NULL,
  PRIMARY KEY (`key`)
)
ENGINE = MyISAM
CHARACTER SET utf8 COLLATE utf8_turkish_ci;

Bilgisayar Ruby (Ruby on Rails) SQL

Merhabalar,

Bir Önceki yazımıza kaldığımız yerden devam ediyoruz. Bu sefer Kyoto Cabinet’in insert (kayıt ekleme) performansını inceleyeceğiz.

Öncelikle bu bir performans çalışması olduğu için makinamın Özelliklerini verelim;
– 2 x AMD Athlon x64 3800+
– 2 G Ram
– Ubuntu 10.04 LTS
– FileSystem ext4
– Ruby 1.8.7 (2010-01-10 patchlevel 249)
– KyotoCabinet 1.2.2
– KyotoCabinet ruby kütüphanesi 1.14

En azından bu Özelliklerle yapılan bir test sizleri kodu kendi makinanıza alıp denemeniz için cezbedebilir. Sonuçta bir Önceki yazıdan kurulum işlemleri uygulayıp sonrasında aşağıda belirteceğim kod parçasını uygulayacaksınız. Sonuçları benimle paylaşabilirsiniz.

require 'kyotocabinet'
include KyotoCabinet

DB::process('subscribers.kch') { |db|
  # resmi sitede yer alan Örneklerde set_encoding olarak gÖsteriliyor fakat aslında tune_encoding olmalı.
  db.tune_encoding('utf-8')

  # Telco sektÖründe çalıştığımız için, numara bir MSISDN'e benziyor degil mi :)
  start_number = 905000000000

  start_time = Time.now
  puts "sira;gecen_sure;toplam_gecen_sure"
  100.times { |index|
    first_loop_start_time = Time.now
    10000.times {
      start_number += 1

      # Evet alt satirda KyotoCabinet üzerinde "Insert" islemi yapıyoruz.
      db[start_number] = start_number
    }
    loop_elapsed = Time.now.to_f - first_loop_start_time.to_f
    total_elapsed = Time.now.to_f - start_time.to_f
    puts index.to_s + ";" + loop_elapsed.to_s + ";" + total_elapsed.to_s
  }

  puts "1.000.000 kayit eklenmistir. Toplam süre: " + (Time.now.to_f - start_time.to_f).to_s
}

ruby kyoto_test01.rb > output.csv ile çalıştırırsanız çıktı dosyasını bir office programında açar ve performans analizinizi daha hızlı yapabilirsiniz. Unutmadan uygulamayı Netbeans veya Scite gibi editÖrlerin üzerinden çalıştırmayın toplamda benim makinamda 3 sn gibi fazlalıklara neden oldular.

İşte benim makinam üzerindeki sonuçların bir Özeti;

Bilgisayar Ruby (Ruby on Rails)