Rule number 1 in performances debug :

It's always I/O.

If it's not IO, then the code should be REALLY bad.

In my xp as a perf engineer, it's always the database. If it's not the db - you don't have severe perf issues

You both should look up Liebig's law of the minimum.

As @stop hints to, it will depend on the project, if it has a database its usually the culprit but it can also be some external service where I/O it the problem (because their database is slow :P).

If those are fast enough and you still think you have performance problem I would guess you have very high demands, like in the realm of first person shooter PVP or remote drone operator ;)

@Voxera well, it's either that or a monkey wrote the code while a racoon was working on configurations. That's the only explanation I have for why else would the application be slow.

@stop while it's true in general, I wouldn't rush to apply it for software. Well OK, it applies, but it doesn't give you any good. It would, however, if all your app's transactions were very similar to each other, or that bottleneck was a resource shared by all app transactions and it was a SEVERE bottleneck.

But in my xp, say, if the network is the bottleneck, you may not feel it in TXs which don't make additional NW calls. The same applies to the database -- if the DB load avg is ~2k, most of your DB-related TX will slow down, BUT others (e.g. ones that fetch data from cache or just compute smth) won't feel a thing.

Sometimes the common denominator is the problem, other times - it's not. That's why our clients need perf engineers as a separate role.

Unless The New Junior used an 2^n algo, it is always an IO issue.

@netikras well,if they manage to create code thats so slow ghat the db is not to blame (and I include the calls to the bd along with queries in the db realm) I am impressed they even got it to work :P

Ot many things can slow things down as a big db with bad queries and indexes.

If the processing includes some Blender 3D rendering, chances are it's neither IO nor DB...

My rule 1 is looking for failures in writing meaningful/reasonable code. They are the low hanging fruits all the time

DB, Network and IO performance issues come much later

@netikras it might be Redis cache badly used, but we can fit redis as "in memory DB" tho

@NoToJavaScript I see that as DB generally.