15
irene
53d

First month of project we suggest that we test that Entity Framework has made reasonable DB queries because the system will need to handle a lot of records. “Not a priority in this sprint because we need features.” Devs try to get it into every sprint. The last week of the project they want us to dump in a ton of records so they can test it. The N+1 SELECT query issue is on main queries. It is so bad and slow with more records that a simple query causes the container management to auto scale the application on a single query. They can have max 8 users in the system at a time and it will take 10 seconds to do a simple page refresh.

They get on our case and we dredge up all of the correspondence where they completely ignored our advice. Fix it now! We need another sprint. Fix it free! No.

Comments
  • 3
    This is why I dapper 😆

    I guess you could just write a quick test suite and dump using ToTraceString()
  • 1
    The EF code im working with is so badly written that it takes around 2min to be able to see around 300 records on a page. PM is absolutely fine with it and he doesnt want pagination. 🤣
  • 1
    @SortOfTested what does dapper mean?

    @irene @Benutzername

    This is sad.... And should be punishable by torture.

    I usually monitor slowlog statistics, which are easily monitorable in every database system.... This should be default with very low defaults.
  • 2
    @IntrusionCM
    Dapper is a microorm. It takes a context, executes the query and automates things like binding parameterized queries and abstracting away the dataset -> T boilerplate.

    Fat ORMs have too much abstraction and introduce too much labor and tech debt for my taste
  • 0
    @SortOfTested ah...

    So handling hydration of objects / data mapping.

    https://github.com/StackExchange/...

    Found it. Was very confused since I thought it was an adjective in your sentence, not a noun xD
  • 1
    EF can only do so much. If you write your statements without knowing what the EF is going to translate it to, you're not going to get good results. You have to have a certain understanding of what's going on under the hood.

    Also, your query is only half the story. What does the schema look like? What indexes do you have and is your db engine using them when you expect? It's all important when it comes to performance.
  • 3
    @spongessuck If you have to know what the ORM will barf out you may as well just write SQL. EF was selecting all entries then scooping the 20 needed for pagination at the back end. I wasn’t on that part of the dev team BTW but it seemed like a really easy mistake to make.
  • 0
    @irene it is an easy mistake to make, but it's something you'll be able to remedy before it gets to production if you're paying attention and have a clue.
  • 0
    @spongessuck Yeah. That one was two months from initial commit to production version. None of us had used EF. We advised them to let us bite the tech debt but the executive let them dump extra stories into the end of each sprint. That went like that for six months and we only had minimum allocated time to address tech debt before they decided to stop funding. No more features? No more money.
  • 0
    @irene I guess they can get what they pay for, then.
  • 1
    @spongessuck It was a big corporate client so in the end they got us to do a few performance fixes said thanks for the system we will get you to rebuild it because we love it. Then they threw millions into it and started the rebuilding based on the old code and threw all the waterfall methodology that they could find at it. It is still inching along at a snail pace with 98% of the original code my team built.
Add Comment