I sincerely hope this will be downvoted out of sight so we won't be dealing with more dog slow sites. Moving business logic to essentially non-scaleable layer is a terrible idea, benefits are so small compared to drawbacks
There are lots of other reasons this is a questionable idea at best, but performance is not necessarily one of them.
Move that logic into a stored procedure and suddenly
your business logic can run in less than the time of
a couple round trips to the database. Lock contention
drops, number of concurrent transactions drops, and
performance could actually increase
Yes! A thousand times yes. This is especially important for write-heavy workloads. Releasing those locks and finishing those transactions ASAP is crucial. There are lots of other reasons this is a questionable
idea at best, but performance is not necessarily one of
them.
When it comes to scalability.... yeah I think the 90/10 rule applies here. Probably the bulk of one's code can comfortably live up at the app layer. And the 10% of your code that's causing 90% of the bottlenecks is a candidate for solutions such as moving it down into the data layer, when feasible.Normally the bottleneck of scaling an application is data access and storage, there aren't typically a lot of problems that are CPU bound.
Adding additional layers doesn't increase performance, it increases latency and processing time. The closer you can keep your processing logic to the actual data, the better your performance is going to be.
That being said, there are reasons why you may not want to follow that architecture, but generally performance isn't going to be one of them.