none
LINQ ve Ado.Net RRS feed

  • Soru

  • Merhaba Arkadaşlar;

    Merak ettiğim Performans farkı şu şekilde.

    Entity Data Model ile normal metodlar ile SQL üzerinden store prosedure işlem yapmak arasındaki hız farkı nedir.

    (Yani connectionString vs şekilde yazılan sistem. Kusura bakmayın adını tam bilmiyorum. ADO.NET di sanırım.)

    Lokalde EDM diğerine göre biraz yavaş gibi geldi.

    Sizce Dinamik bir Web sitesinde hangisini tavsiye edersiniz?

    EDM mi Klasik uzunyol mu?

    Cümle ve anlatımda kusurum oldu ise affola.

    Saygılarımla....

    8 Ocak 2014 Çarşamba 20:51

Yanıtlar

  • Cihan beye kesinlikle katılıyorum. Ayrıca şunu da belirtmek lazım ki Entity Framework 6.0 itibari ile düzgün bir algoritma ile performans sorunu o kadar büyütülecek bir konu değil. Mesela 10 kolonlu bir tablonuz var ve burdan size 2 kolon gerekiyor. Bunun için muhakkak select yaparak sadece işinize yarayan kolonları çekmeniz gerekmekte. Tabi bu dediğim 100-200 satırlı bir tabloda pek fark etmez ama çok büyük verilerle uğraşırken önemli derecede etki edecektir. Ayrıca şunu da unutmamak gerekiyor, bazı kompleks sorgular vardır. Siz bunları kendinize göre yazdığınızda belki daha çok performans sorunu yaşayacaksınız ama entity framework tarafından yaparsanız bu işlemi sorguyu optimize ederek hazırlayacaktır size.. Ayrıca şunu da belirtmek isterim SQL Server 2014 ile gelen In-Memory OLTP sayesinde artık performans tavan yapma durumuna geliyor. Microsoft tarafından verilen örneklerde (kendimizde şahsen denemiş bulunmaktayız) 1 milyon veriyi 3 saniye gibi bir sürede ekledik veritabanına. Ayrıca tavsiyem entity framework tarafında da kompleks olmayan işlemleri stored procedure ile işlemlerinizi yapmanız. Performans çok ciddi derecede artmaktadır..  Son olarak SQL Server 2014 üzerinde In-Memory OLTP ile ilgili sevgili dostum Ali Serdar GÖKÇEN tarafından hazırlanan şu videoyu izlemenizi tavsiye ederim. 

    http://www.youtube.com/watch?v=hXEBdhkkttY


    Oğuz KURTCUOĞLU - Professional Software Developer

    • Yanıt Olarak İşaretleyen Tolga_Cakir 12 Ocak 2014 Pazar 10:51
    9 Ocak 2014 Perşembe 07:24

Tüm Yanıtlar

  • Burada amaç performans değil ! Hızlı yazılan, güvenilir , sağlam , bakımı kolay, genişletilebilir kod yazmak. Tüm bunları sağlandığında performans kaybı kendini çoktan amorti etmiş oluyor.  Bununla ilgili forumda oldukça fazla yazı var inceleyebilirsin. Hiç bir şekilde düz ado.net kullanılmasını tavsiye etmem! İyi kod hızlı çalışan kod demek değildir. Performansı tek ölçüt olarak alırsanız burnunuz bugdan kurtulmaz.
    • Yanıt Olarak Öneren Taner ÇOLAK 9 Ocak 2014 Perşembe 03:17
    8 Ocak 2014 Çarşamba 21:47
    Moderatör
  • Cihan beye kesinlikle katılıyorum. Ayrıca şunu da belirtmek lazım ki Entity Framework 6.0 itibari ile düzgün bir algoritma ile performans sorunu o kadar büyütülecek bir konu değil. Mesela 10 kolonlu bir tablonuz var ve burdan size 2 kolon gerekiyor. Bunun için muhakkak select yaparak sadece işinize yarayan kolonları çekmeniz gerekmekte. Tabi bu dediğim 100-200 satırlı bir tabloda pek fark etmez ama çok büyük verilerle uğraşırken önemli derecede etki edecektir. Ayrıca şunu da unutmamak gerekiyor, bazı kompleks sorgular vardır. Siz bunları kendinize göre yazdığınızda belki daha çok performans sorunu yaşayacaksınız ama entity framework tarafından yaparsanız bu işlemi sorguyu optimize ederek hazırlayacaktır size.. Ayrıca şunu da belirtmek isterim SQL Server 2014 ile gelen In-Memory OLTP sayesinde artık performans tavan yapma durumuna geliyor. Microsoft tarafından verilen örneklerde (kendimizde şahsen denemiş bulunmaktayız) 1 milyon veriyi 3 saniye gibi bir sürede ekledik veritabanına. Ayrıca tavsiyem entity framework tarafında da kompleks olmayan işlemleri stored procedure ile işlemlerinizi yapmanız. Performans çok ciddi derecede artmaktadır..  Son olarak SQL Server 2014 üzerinde In-Memory OLTP ile ilgili sevgili dostum Ali Serdar GÖKÇEN tarafından hazırlanan şu videoyu izlemenizi tavsiye ederim. 

    http://www.youtube.com/watch?v=hXEBdhkkttY


    Oğuz KURTCUOĞLU - Professional Software Developer

    • Yanıt Olarak İşaretleyen Tolga_Cakir 12 Ocak 2014 Pazar 10:51
    9 Ocak 2014 Perşembe 07:24
  • MVC4 + EDM size ihtiyacınız olan performansı sağlayacaktır. EF'in performans kaybı diğer getirileri yanında gözardı edilebilir.  MVC'ile ASP.Net in hantal yapısından da kurtulursanız sonuçta karda olan siz olursunuz.

    e-mail: onay[nokta]yalciner[at]hotmail[nokta]com
    MCC

    • Yanıt Olarak Öneren Ali İldan 18 Ocak 2014 Cumartesi 21:12
    9 Ocak 2014 Perşembe 12:52
    Moderatör
  • Burada amaç performans değil ! Hızlı yazılan, güvenilir , sağlam , bakımı kolay, genişletilebilir kod yazmak. Tüm bunları sağlandığında performans kaybı kendini çoktan amorti etmiş oluyor.  Bununla ilgili forumda oldukça fazla yazı var inceleyebilirsin. Hiç bir şekilde düz ado.net kullanılmasını tavsiye etmem! İyi kod hızlı çalışan kod demek değildir. Performansı tek ölçüt olarak alırsanız burnunuz bugdan kurtulmaz.

    Herşey ORM değildir, Binlerce kullanıcı bir sisteme aynı anda yüklendiğinde yada ORM tutkunu ama sql den nasibini almamış bir programcı işleri felakete çevirebilir...(Ne kadar düzgün algoritma kullanırsa kullansın...)

    Oğuz'un burada bahsettiği ADO.NET DataTable, Dataset ve TSQL sorguları değil.

    POCO tarzı kodlama ile sıfır tsql ile entitynin yaptığı işi biraz daha emek harcayarak hem ileride oluşacak performans kaybı hem kodlama daki sorunları azaltmış olursunuz.

    Dapper:

    https://code.google.com/p/dapper-dot-net/

    ServiceStack ORM.Lite:

    https://servicestack.net/

    PetaPoco:

    http://www.toptensoftware.com/petapoco/

    Bunlar entity den daha hızlı ve daha compleks bir yapı sağlar.

    Düşünceniz bana çok tutarsız geldi. Çağ artık masaüstünde direkt db ye bağlan hızlıca verileri al kurtul çağı değil. Şuan nerdeyse bir çok hizmet cloud a geçiyor. Burada kod performansı etkili olacaktır.

    Bunları dikkate alarak yazdığınız cevabı tekrar gözden geçirin bakalım ne anlayacaksınız.

    İyi akşamlar.


    12 Ocak 2014 Pazar 16:23
  • Ne anlatmak istediğini ya da benim yazdığımdan ne anladığını anlamadım. Ben spagetti değil object oriented kod yaz diyorum kabaca. Tek kriterin performans olmadığını anlatıyorum performansın bir kriter olmadığını değil.
    12 Ocak 2014 Pazar 21:10
    Moderatör