One employee explained something to another, while i was walking by.
He: "... now we have 800 instead of 4000 on this Page ..."
Me: "Miliseconds?"
He: "Executed sql querys"

WTF?!?

I wish I did not recognize the situation :/

Not quite 4000 but I have seen numbers over 1000 on some pages. :(

N+1 ;D

I did something like that.
They gave me an application, which is fully configurable (the core is used by a lot of different implementations, that's why its fully customizable), but it was SLOW.
I'm not talking of a simple "slow web page", but more something like "I qould kill your whole family if this page wouldn't f*cking load" page.
There is a page which contains a form (not just a <form>, but a real form, which every input is configured in database) and this page did like 2000 queries.
30 checking inputs. 2000 queries.

I managed to go down to 400, but it was impossible to go further without rewriting the entire core.
I mean, hearing "I managed to reduce queries from 2000 to 400" may sounds stupid, but you can't guess what there is behind to obtain that result!

@taglia A lot of the problem is often that the pages either contains a lot of details even if some is not immediately visible or using a very broken backend.

One such was a list that was created by first querying for all ids if objects to show and then loop over and create objects that was used to render.

Problem was that each object used a dozen queries to load all its data (not just that which was needed for the list) and the limit for what was to be shown was done after loading all objects, not before so it loaded over 120 objects times 12 queries and then only showed the names of 10 of them in a list.

A quick rewrite so that the first query also fetched the names cut the page from over 1000 queries down to ~12.

Another good way is to use caching for all data that is not required to be 100% up to date. This also avoids multiple fetch when the same data is needed deep into different business components.

I asked them again... They told me that it's the number of entries in the SQL Server Profiler and that there are 4 entries for each query...
So there are 1000 and 200 real executed queries which is a little less bad....

@taglia It sems to be a similiar case like yours. However, nobody can change the data except themselves...