We just bought the new version. Mostly to see if we could get some better performance.

For now I have testet load time on our website using a tool called webserver stress tool 7. And in general the response from the version with LLBLgen 4 is slower than our old with 3.5

We have a lot of small queries and do a lot of prefetches, but never fetch 30.000 entities at a time.

LLBLgen v3.5 build january 17 2013

We use selfservicing

The test is not done in a seperate environment, but queries are called in same periods to both websites running on same webserver. I have rerun the test with a few minutes in between, which is why there is more result for same page with same llblgen version.

Test results. (A click is what it takes to download html)

URL No. Name Clicks Errors Errors [%] Time Spent [ms] Avg. Click Time [ms] First page 1 llblgen 3.5 41 0 0,00 43.904 1.071 2 llblgen 4 41 0 0,00 42.581 1.039 1 llblgen 3.5 46 0 0,00 16.578 360 2 llblgen 4 45 0 0,00 21.215 471

Second page 1 llblgen 3.5 45 0 0,00 28.827 641 2 llblgen 4 45 0 0,00 31.003 689 1 llblgen 3.5 46 0 0,00 21.699 472 2 llblgen 4 46 0 0,00 22.493 489

Third page 1 llblgen 3.5 50 0 0,00 197.155 3.943 2 llblgen 4 48 0 0,00 295.502 6.156 1 llblgen 3.5 50 0 0,00 242.827 4.857 2 llblgen 4 48 0 0,00 302.474 6.302 1 llblgen 3.5 50 0 0,00 293.818 5.876 2 llblgen 4 48 0 0,00 293.321 6.111

Does this sound unexpected for you guys? Or is it expected that the small queries that only returns 1-2 entities is slower in the new version where its faster if you fetch a lot of entities in one go?

What should be our next step. Just hold off on the update and continue with 3.5?

// Jacob

You should use a profiler, to see where the extra time is spent/wasted. Which database type/version are you using?

This isn't expected. With 1-2, 10 etc. entities the queries also should be faster, simply because there aren't any entityfield objects created. With small amount of entities, it might be the difference isn't that visible though (if at all). The reason for that is that your application likely spends < 10% of its time in the ORM code, and if you fetch just a few entities, the speed increase for fetching 1-2 entities is not really visible.

Without a profiler, it's not clear where the time is spent, so use a profiler like dottrace or ants to see where your application spends its time. Also, always measure with release builds.

btw, in your list, there are v4 usages which are faster than v3.5's, so it might be the difference you're seeing is due to something else.

Thanks for your replies.

I agree with your comment that it could be something else. We do a lot on some of the pages.

We also cache some of the entities in asp.net cache where it makes sense. Will the use of the new cache mechanisme in v4 be faster than just saving a CustomerCollection or List<CustomerEntity> in asp.net cache.

I'll have to postpone extensive tests to a more suitable time.

No worries We're currently running benchmarks on selfservicing and do see it's slower than adapter, and with a margin we didn't expect (as the fetch code is the same code).

These benches are over the network, so network latency is included in the timings.

Adapter:

Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1105ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 718ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 819ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 737ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 800ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 763ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 796ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 802ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 769ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 768ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 772ms
Fetching 31465 entities individually through CTor/PK fetch took 51233ms, or 1,62825361512792ms/entity
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 733ms
Fetching 31465 entities individually through CTor/PK fetch took 50992ms, or 1,62059431113936ms/entity

selfservicing:

Fetched 31465 SalesOrderHeader entities, to warm up DB
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1118ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1109ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1127ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1118ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1127ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1105ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1126ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1097ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1097ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1139ms
Fetched 31465 LLBLGen Pro v4 entities from the DB. Took 1087ms
Fetching 31465 entities individually through CTor/PK fetch took 49715ms, or 1,58000953440331ms/entity

So Selfservicing is, per collection, 250-300ms slower than adapter, which is unacceptable (there's something off there, we're looking into that). Per entity, it's faster.

per entity fetches are slower because for each entity fetch a query has to be generated, a connection has to be opened/closed, a command has to be created etc. Still, as you can see, fetching an entity will take as much as ~1.6ms in total in our test situation, so barely significant. This is v4 code, v3 might be a tiny bit slower in the individual entity fetches because it creates individual fields to store field data, but as each query in v4 creates individual fields as well, it's not really a disadvantage of v3, as v4 will not benefit in this regard of the optimizations we added.

In v4 we avoid creating entity fields in an entity instance for storing the field data, which offers a big speed increase. As individual entity fetching does require a query to be generated, which creates all fields, it's not going to be faster in v4 that much. For that we have to cache queries so they can be re-used, which didn't make it in v4.0

We also cache some of the entities in asp.net cache where it makes sense. Will the use of the new cache mechanisme in v4 be faster than just saving a CustomerCollection or List<CustomerEntity> in asp.net cache.

Caching what you already fetched and created as objects is always faster than re-materializing new objects. The caching we implemented avoids re-reading the data from the DB, but entities are still created, a query is still created, and a connection is still opened. So caching data you already have at that level, so you can just pull the objects from the cache and re-use them is faster.

Try to cache as high up in the call chain as possible. If you can cache page fragments (user control output for example) it's better than re-creating these fragments each time, as it's all about the work you avoid.

We'll get back to you on the selfservicing set fetch speeds.

The difference between Selfservicing and Adapter is caused by: 1) each selfservicing entity has persistence info inside itself, this is obtained at entity creation time. This takes ~250ms in total over the 31,000 entities fetched, so ~0.008ms per entity, which is nothing on individual entity basis but still it adds up with a massive load of entities. Adapter doesn't have this, it obtains this info once per query 2) Adapter doesn't create member collections, selfservicing does. This time is, per entity, insignificant, but when you fetch 31K entities, it does add up a bit.

This in total makes the difference between adapter and selfservicing.

We did find a redundant fields creation call in the selfservicing code though, so we have refactored that out in the runtime. It had ~5-8% influence, so set fetches are a little faster now in selfservicing (next build), but we can't get it closer to adapter at this point. In general this isn't that big of a deal, it's still faster than v3 and has a much lower memory footprint.