Başlıktan da anlaşılacağı üzere bu testimde kendi bilgisayarımda EF ve FNHibernate’i karşılaştırdım ve performans grafiğini çıkardım.
Bahsi geçen işlemleri elimden geldiğince aynı datalar üzerinde uygulamaya çalıştım. Şimdi işlem işlem performans sonuçlarını görelim isterseniz.
Not: Tüm işlemler BULK(Toplu) olarak yapılmıştır. Yalnızca adet olarak “tekil” belirtilen işlemler tek başına yapılmıştır.
INSERT İŞLEMİ |
||
Adet | 10.000 | |
Entity Framework | 26.576 | ms |
Fluent NHibernate | 4.695 | ms |
Adet | 25.000 | |
Entity Framework | 185.167 | ms |
Fluent NHibernate | 9.251 | ms |
Adet | 1.000.000 | |
Entity Framework | 34.275.210 | ms |
Fluent NHibernate | 325.595 | ms |
Evet, tabloda da göreceğiniz üzere bu aşamada FNHibernate ciddi bir +performans farkıyla karşımıza çıkmaktadır.
INSERT İŞLEMİ (NON-CLUSTEREDINDEXES) |
||
Adet | 10.000 | |
Entity Framework | 27.121 | ms |
Fluent NHibernate | 4.785 | ms |
Adet | 25.000 | |
Entity Framework | 179.406 | ms |
Fluent NHibernate | 10.786 | ms |
Adet | 100.000 | |
Entity Framework | 717.321 | ms |
Fluent NHibernate | 46.908 | ms |
Bilindiği üzere Non-Clustered Index olan bir tabloda veri yazmak kimi zaman bir işkence halini alabilmektedir. İşte bu noktadaki birden fazla indexleme yapılmış tabloda da yine Fluent NHibernate EntityFramework’e göre 10 ila 17 kat daha performanslı olarak karşımıza çıkıyor.
UPDATE İŞLEMİ |
||
Adet | 1 | |
Entity Framework | 1 | ms |
Fluent NHibernate | 17 | ms |
Adet | 10 | |
Entity Framework | 13 | ms |
Fluent NHibernate | 29 | ms |
Adet | 1.000 | |
Entity Framework | 240 | ms |
Fluent NHibernate | 143 | ms |
Fluent NHibernate bu alanda tekil transaction’da her ne kadar bir tık geride gibi dursa da bu sizi yanıltmamalı. Fluent NHibernate ile ilgili daha sonra yazacağım makalelerde de bahsedeceğim üzere FNHibernate insert ve update işlemlerini transaction_scope() içerisinde gerçekleştirir. Bu da hatalı yapılabilecek bir işlemde kaydı geriye döndürme imkanı sağlamaktadır bilindiği üzere. Bu nedenle aslında burada 1-10 kayıt dolaylarındaki bu yavaşlık tamamen transaction_commit() işleminde doğmaktadır. Yoksa Update işleminin geneline özel bir yavaşlığı kesinlikle söz konusu değildir. Zira 1000 kayıtta bu performansı çok net görebilirsiniz. Yani düz hesap şunu diyebiliriz; Update 1ms, ama transaction_commit() toplamda yaklaşık 16ms. 🙂
SELECT İŞLEMİ |
||
Adet | 10.000 | |
Entity Framework | 568 | ms |
Fluent NHibernate | 920 | ms |
Adet | 25.000 | |
Entity Framework | 835 | ms |
Fluent NHibernate | 2.131 | ms |
Adet | 1.000.000 | |
Entity Framework | 22.412 | ms |
Fluent NHibernate | 38.669 | ms |
ID SELECT İŞLEMİ |
||
Adet | 1 | |
Entity Framework | 315 | ms |
Fluent NHibernate | 939 | ms |
Adet | 5 | |
Entity Framework | 323 | ms |
Fluent NHibernate | 1.266 | ms |
İşte, testlerimde EntityFramework ile kapışamadığı tek nokta burası. Tüm testlere rağmen tekil ve çoğul select işlemlerinde Fluent NHibernate bir tık geride kalıyor. Tabi bu noktaları belli başlı methodlar izleyerek rahatlatmak ve EntityFramework’ten farksız hale getirebilmek mümkün. Ancak bunu ayrı bir makalede bu işlemleri anlatırken detaylı izah ediyor olacağım.
Şimdilik bu kadar. Umarım faydalı bir test işlemi olmuştur. Bir sonraki yazımda da başka bir ORM olan PetaPoco ile EntityFramework ve Fluent NHibernate’i karşılaştırdım.
O makalemi de en kısa zamanda paylaşıyor olacağım.
Şimdilik okuyan herkese teşekkürler. Sorularınız olursa lütfen aşağıdaki yorumlar alanında sorunuz. En kısa sürede yanıtlamaya çalışacağım…