Category Archives: NHibernate

EF őrület

Ha az NHibernate tudja, hogy identity id generálási stratégia mellett, ha egy ojjektumnak nem 0 az idja, akkor az perzisztens, így nem kell újra beszúrni, az miért nem megy az EF-nek?

Próbálom használni az EF-et anélkül, hogy lemappelném az FK-kat property-ként, de látom széllel szemben megyek. Nincs cascade szabályozás sem, így ez úton nem mondhatom neki, hogy csak a gyereket szúrd be, a szülőt ne, mert az már perzisztens. Ah. Értem én, hogy nem ebbe az irányba kell haladnom, mert szembe fúj a szél, de nem szeretem azokat a modelleket, ahol az fk le van mappelve. Leaky abstraction. Az EF inkontinens, ez kell neki, a fene a hugyos józsiját.

Védje meg valaki, vagy mindjárt visszatérek NHibre, és kivágom a projektből az EF-et.

Memória táblák meghajtása OR mapperrel

Az SQL Server 2014-es memóriatáblákat csak akkor lehet a lehető legközvetlenebb módon elérni, ha natív kódra fordított tárolt eljárásokkal érjük el. Az OR mapperek viszont alapban sima, dinamikus SQL-eket generálnak. Ha így akarunk CRUD műveleteket végrehajtani egy memória táblán, akkor az átmegy a szerver interop rétegén, ami jelentősen belassítja azt. Többszörösére. Emiatt -jelen tudásom szerin-, ha OR mapperel akarjuk meghajtani a memória táblákat, akkor saját spket kell írni. Kipróbáltam a dolgot, de falakba ütköztem. Ugyanis az OR mapperek elvárják, hogy pl. egy update után visszaadja a szerver az xxx rows affected information message-et, ebből tudja az OR mapper, hogy sikerült a sor módosítása. Ha nem jön vissza semmi, akkor azt hiszi, hogy az optimista konkurencia ellenőrzés miatt nem sikerült a sor módosítása (azt hiszi valaki közben módosította vagy törölte a sort), így exceptiont dob. Viszont a memória táblás update NEM adott vissza XXX rows affected üzenetet, így az OR mapper exceptiont dob (NHibernate.StaleObjectStateException és ).
A megoldás tehát valószínűleg az lehet, hogy ki kell kapcsolni az OR mapper optimista konkurrencia ellenőrzőjét.
Egyelőre NHibernate-nél nem találtam megoldást rá, legalábbis a Conf ORM-es “code first” mapping módszerrel. EF-en még nem próbáltam.
Mindenesetre kiírtam msékhez a kérdést, ha jön válasz, megírom.

Az ORM batching perf vonzata

Az egyik ügyfelemnél letöltenek pár száz sort memóriába Entity Frameworkkel. Ott C# kóddal mindenféle komplex módon kitalálják, melyik entitást hogyan kell módosítani, majd a módosítások eredményét az EF betolja adatbázisba. Bár a szerveren nem volt nagy terhelés, mégis volt amikor 1000 fölött volt a batch request/second.

Miért? Mert az EF nem tudja összenyalábolni a módosításokat, hanem egyesével küldi be őket. Azaz, ha 300 sor módosult, akkor 300 update fog bemenni, ennyi roundtrip lesz. Ez annyira gáz, hogy egyszerűen nem értem az MS-t, miért nincs még batching a 6-os EF-ben.

Mutatok egy példát, mekkora hatása van ennek. Az NHibernate bármennyire is elhanyagolt manapság, de ő szépen tud batchelni.
A következő példában letöltök 20000 sort, módosítom mindet, majd visszamentem a módosításokkal. EF-fel ez 11mp.
NHibernate-tel meg tudom mondani, hány utasítást küldjön be egyszerre. Ettől függően az alábbi számok jönnek ki:

NHib test - BatchSize: 1000000, Duration: 00:00:00.9390957
NHib test - BatchSize: 100000, Duration: 00:00:00.8363326
NHib test - BatchSize: 10000, Duration: 00:00:00.8463299
NHib test - BatchSize: 1000, Duration: 00:00:01.0654756
NHib test - BatchSize: 100, Duration: 00:00:01.3361271
NHib test - BatchSize: 10, Duration: 00:00:02.4312424
NHib test - BatchSize: 1, Duration: 00:00:10.4669159

Elég nagy batch méretnél a 10 mp lemegy 1mp alá!
EF-nél 11, és kész. Cáfoljon meg valaki, hogy rosszul tudom, és az EF is tudja ezt.