• ray10k (unregistered)

    Wait, doesn't this mean that a badly timed restart of the system user-side could result in part of/the entire config getting deleted? Or am I misunderstanding the order of operations here?

  • MiserableOldGit (unregistered) in reply to ray10k

    It does read like a race condition, but that isn't mentioned and you would have thought it would be a screamingly obvious PITA if, indeed, it was happening.

    Maybe that menu_cfg is in user-specific space and this is a cack-handed attempt at caching the conversion "configuration options" into an actual UI.

    Whatever, inefficient and daft though it is I can't see why it causes such an extreme bottle neck for 400 rows and 16MB unless the network is really crap, or the database/server has "issues". I suppose if that's an example of the code quality it's a good guess there's plenty of other crap in there.

  • (author) in reply to ray10k

    Presumably there's a transaction in there, somewhere? But given this site, should we assume that? Probably not.

  • RLB (unregistered) in reply to MiserableOldGit

    Whatever, inefficient and daft though it is I can't see why it causes such an extreme bottle neck for 400 rows and 16MB unless the network is really crap, or the database/server has "issues". I suppose if that's an example of the code quality it's a good guess there's plenty of other crap in there.

    Hm, let's say... a judicial use of a lack of indices?

  • (nodebb)

    It takes 30 seconds to perform an operation on 400 rows. Does that mean to do anything affecting 40,000 rows, it'll spin for almost an hour? Don't add any new menu items!!! Use buttons instead.

  • MiserableOldGit (unregistered) in reply to RLB
    Hm, let's say... a judicial use of a lack of indices?
    I don't think even none at all would be enough .... a massive overuse of them causing escalation deadlocks, perhaps. In fact I've seen precisely that (in combination) with some very amateur transaction work in the client.
  • Scott (unregistered)

    When I got to my last job, the idiot IPCs (inexplicably paid consultants) were trying to convince the boss that more memory had to be added to the db server, because we'd occasionally experience slowdowns in our main application. This application was very old, and poorly written even then.

    I pointed out we had ~50 users. There's no way on earth that SQL Server can't handle the load we're putting on it. Did a little poking around, discovered that the main search function returned every row which qualified (and then displayed only one page of those results). As a bonus, the sproc underneath it all was vulnerable to injection attacks.

    Explained all this to the boss, added a "new search" functionality (so we could before & after test--of course nobody had requirements) using EF/linq's built-in paging with take & skip. Got that tested out, released it--surprise, no more timeouts.

    IPCs complained that EF & linq was "too hard", because "they're database guys."

    A couple of humorous follow-ups.:

    When we decided new search was good, we took away the old search from the menu, and renamed "new search" to just "search". in other words, went from two search menu options to one. Users froze up--"where's the new search, that was great". "Did you try to click the only search option now available?"

    Somewhat later, I had SQL Profiler running, trying to figure out how a 3rd party tool queried the database. One of the IPCs, (remember, self-proclaimed "database guy"), wandered by and asked me what that tool was. Sigh.

  • King (unregistered) in reply to Scott

    There are only three hard things in programming: naming, caching and idiots.

  • Osric (unregistered) in reply to King

    You forgot "the feeling of you desk hitting your forehead" from that list.

  • Aaron (unregistered)

    TRWTF is why there was no syntax error on DELETE * FROM MENU_CFG;

    Most people use DELETE FROM MENU_CFG; or TRUNCATE TABLE MENU_CFG;

Leave a comment on “Slow Load”

Log In or post as a guest

Replying to comment #:

« Return to Article