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 olduğumuz) projem de redcar + jruby 1.6.3 + rails 3.0.9 + mysql >5 (arabirim olarak mysql workbench) ortamında yazılım geliştirme gerçekleştirdim.
Neden redcar;
- Netbeans Build-in debugger’ı code-complete özelliÄŸi ile tam bir editör ama 6.9.1’den sonra desteÄŸi yok.
- Redcar’ın kısa yolları ve “snippet” lerine alışırsanız oldukça hızlı ve efektif ÅŸekilde uygulamanızı geliÅŸtirebilirsiniz.
- DiÄŸerlerini denemeyin bile :)
Neden MRI deÄŸil de jruby kullandığımı soracak olursanız, cevabı yukarıdaki parantez içerisinde yazdığım küçük cümlecikte saklı. Evet malesef rails için windows üzerinde yüksek TPS deÄŸerlerine eriÅŸebilecek bir sistem kurmak oldukça zor ve problemli. Bu nedenle jruby ile java‘nın bu getirilerinden faydalanmak istedim.
JRuby’nin bu gücünü kullanmak içinde bazı çalışmalarım oldu. GlassFish, Tomcat :) hatta IIS üzerinde koÅŸturup, performans deÄŸerlerini inceledim. Tomcat ve IIS için pek olumlu konuÅŸamayacağım, belki de ayarlarını tam yapamadığım için olabilir ama GlassFish gerçekten iyi bir performans grafiÄŸi çizdi. GlassFish’in tek kötü yanı çok büyük ve gereksiz birçok bileÅŸen içermesi ama elbette bazı projelerin bu bileÅŸenlere ihtiyacı olabilir, bu durumda tercih edilebilecek bir sunum ortamı olabilir.
Benim tercihim ise jetty oldu. jetty_rails adlı bir eklenti ile işler kolaylaşıyor fakat ne yazık ki eklenti oldukça eski bir sürüme ait bu nedenle bazı ufak tefek düzeltmeler yapmamız gerekiyor. Lafı çok uzattık bu düzeltmeleri daha sonra sizlerle paylaşırım.
Son söz olarak, rails uygulamanızı yazarken aşağıdaki maddeleri göz önüne almanızı tavsiye ederim;
- Rails uygulamanızı kendiniz host etmeyin.
- Rails uygulamanızı gerçekten kendiniz host etmeyin.
- Rails uygulamanızı Linux bir sunucuda host edin. Linux için zilyon tane başarılı alternatifi deneyebilirsiniz.
- Rails uygulamanızı Windows sunucuda host etmeyin.
- Rails uygulamanızı Windows sunucuda host etmeyin, gerçekten.
- Rails uygulamanızı Windows üzerinde host etmek istiyorsanız, jruby uyumlu olmasına özen gösterin. Host etmek istediğiniz zaman duruma göre glassFish veya jetty kullanabilirsiniz.
Kolay gelsin :)
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.
Ruby ile Kyoto Cabinet – 5 yazısına devam et
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;
Ruby ile KyotoCabinet – 3 yazısına devam et
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;
Ruby ile KyotoCabinet – 2 yazısına devam et
Merhabalar,
Uzun bir aradan sonra kendimde tekrar yazı yazabilecek enerjiyi bulabildim. Nasıl mı? Aslında ben de bilmiyorum. Yeni doğan kızım Nil (evet, artık benim bir kızım var, kendisi daha 22 günlük :) ) nedeniyle evde çok neşeli bir telaşımız var ama yine de bir cumartesi akşamı ben bu yazıyı yazabiliyorum.
Ayrıca bugünün cumartesi olması ve ÅŸu saatlerin de akÅŸam olması ve artık bir kızımın olması nedeniyle ilk kez akÅŸam gezintileri için “benden geçmiÅŸ” demek zorunda hissettim kendimi. :)
Neyse konumuza dönelim, konumuz Kyoto Cabinet‘in ruby’de kullanılması olacak. Öncelikle
Kyoto Cabinet nedir;
Aslında bilenler var ise Kyoto Cabinet, Tokyo Cabinet gibi, Memcache gibi yüksek performanslı non-relational (türkçe çevirisi için ‘iliÅŸkisiz’ den daha iyi fikri olan söylesin) veri tabanı sistemidir. Limitleri oldukça yüksektir ve performans konusunda gerçekten dudaklarınızıda uçuklatabilir. Kesinlikle oracle, mysql veya postgre gibi relational (iliÅŸkili) veri tabanı sistemleri ile kıyaslanmamadır. Bu elma ile armut kıyaslanması gibi olur.
Kyoto Cabinet aslında “Key” ve “Value” ikilisini bir veri tabanında (bir dosyada) tutmak ve yönetmek için yapılandırılmış bir kütüphanedir. Bir dosya üzerinde yer alan Key ve Value alanları farklı uzunluklara sahip ve farklı tiplere sahip olabilir. Ayrıca bu kayıtları B-Tree veya Hash olarak tutabilmektedir.
Peki hemen aklınıza bir soru gelebilir. Nedir bu B-Tree ve Hash denen arkadaşlar? Sayfaları ziyaret edin, kullanın öğnenin diyorum başka da birşey demiyorum. Yaptığınız işe göre, kullanmanız gereken algoritmaya göre seçeceğiniz yapı yazılım performasını etkileyen en büyük unsur olacaktır. Ve malesef bunların bir tanesi hepsini dövmüyor/dövemiyor.
Hadi Kyoto Cabinet kuralım
0- Linux’da çalışıyor. Benim kullandığım ubuntu üzerinden kurulumu anlatacağım.
Ruby ile KyotoCabinet yazısına devam et
Merhabalar,
Öncelikle karşılaştırma derken, nasıl bir karşılaştırma yapacağımızı anlatmalıyım. Performans işlemleri karşılaştırma kriterlerim içerisinde bulunmuyor, bundan hiç bahsetmeyeceğim. Ama kodun okunabilirliği, hızlı yazılması, hatalara karşı ne kadar duyarlı olduğu ve tabii ki en önemlisi tekrar kullanabilirliği.
Aslında bu son nokta yani ‘tekrar kullanılabilirlik’ baÅŸlı başına bir yazı konusu ama buna ÅŸimdilik pek deÄŸinmeyeceÄŸim. BaÅŸlıkta yazdığı gibi dosya iÅŸlemlerini karşılaÅŸtıracağım.
Arşılaştırmayı sadece VBScript, JScript ve Ruby arasında yapacağım, neden mi ? hali hazırda yapmıştım da ondan.. bu yazıyı yazacağım diye oturup program yazmadım. Önce programları yazdım, sonra yazıyı yazmak aklıma geldi. Bu nedenle neden diye sormayın. :)
Ama belki daha sonraki zamanlarda Java ve C# versiyonlarının karşılaştırmalarını da eklerim.
Öncelikle sizlere problemden bahsedeyim.
Belirli bir server üzerinde ps ve txt (post script ve text) dosyaları online bir uygulama tarafından oluÅŸturuluyor, daha sonrasında online uygulama üzerinden kullanıcı bu dosyaları temizlemeyi unutuyor ve dosya sisteminin ÅŸiÅŸmesi ile beraber performans problemleri ortaya çıkıyor. Bu nedenle dosyaların gün bazında ömürlerinin olmasına ve ömrünü doldurmuÅŸ olan dosyalarında sistem tarafından silinmesine, silme iÅŸlemi esnasında log almasını ve bu loglarında aynı ömür kuralına tabii olmasını istiyoruz… iÅŸte bu program bu iÅŸi yapacak.. günde bir kez çalışacak ve bu iÅŸlemi yapacak. Microsoft Windows sistemde çalışmasını istediÄŸimiz için VBScript ve JScript’de (JavaScript’in bire bir aynı klonu) ve platform bağımsız olan Ruby’de yazıldı. İşte Ruby örneÄŸi;
Dosya İşlemleri (KarşılaÅŸtırma) yazısına devam et
Merhabalar,
Şu zamana kadar yazdığım yazılarda Ruby ile ilgili pek çok konuya değindik, bu konular arasında POP3 ve SMTP, HTTP ve FTP, Dosya İşlemleri, Çalışma zamanı, Module yapısı, Hata yakalama, Resim işlemleri, ODBC veri tabanı bağlantısı, Ruby nesnelerinin karşılaştırılması gibi konular mevcut. Aslında tüm bu yazılardan küçük bir kitap bile çıkabilirdi ama elbetteki yazım dilinin tekrar bir elden geçirilmesi gerekli. Her neyse, şu zamana kadar yazdığım yazılar umarım sizlerin de işine yaramıştır :). Benim yaradı valla, ben Ruby ile ilgili bazı konularda kendi bloğuma bakıyorum :).
Sözü uzatmadan baÅŸlıktan da anlaşılacağı gibi yazımızın konusuna yani Thread’lere(Türkçe’sini tam kestiremedim, hoÅŸgörün lütfen) geçelim. Åžimdi eÄŸer bir yazılımcıysanız, daha önceden Multi-Thread uygulamalar ile uÄŸraÅŸmıssanız, kolay bir konu olmadığını bilirsiniz. Gerçekten özellikle zor zamanlarda çok uyuz bir konu olabilir. Tüm bunlardan öte, yapımı ve tasarlanması çok pahalıya patladığı için, yazılımcılar tarafından pek tercih de edilmez. Ama iÅŸler Ruby’de biraz daha farklı, çünkü Ruby’de bu iÅŸlemler oldukça basit ve etkileyici :).
Ruby ile Thread İşlemleri yazısına devam et