Why Laravel apps (may) don’t scale well (III)
My third post is about scaling Laravel again. After 6 months of intensive coding on Laravel, as much as I get into the source code, I found more problems that can make a project fail to scale.
Queue
How Laravel manages the Queue is great, easy, a lot of functionality, etc.. but is not suitable for scaling applications.
- Do not support RabbitMQ or Kafka, most used Queue servers for scaling up.
- Laravel Horizon can run only on one server. You can put a different queue in each server but is not a true scaling solution.
Carbon
Using Carbon Dates is extremely dangerous if you don’t know how it works. Each instance takes nearly 1kb of memory. If you have a collection of models using Carbon properties, you will get out of memory soon. And if you are scaling your app, the problem will be bigger.
But is not the only problem. If you put in the cache objects using Carbon dates, you going to exhaust the Cache.
Eloquent
All ORMs have their pros and cons. Eloquent have a lot of functionality, is incredible how many functions exist.
Is like entering a carpentry workshop with lot of mechanical tools. I’m very sure if you are not an expert, you are going to eventually hurt yourself.
And the real problem with Eloquent is that you don’t know what is doing under internally. So functions like whereDate, whereDay, etc… are making your query not using the indexes. Yes, if f*cking your server.
whereDate(‘2022–05–25’) is translated to DATE(column)=’2022–05–25' instead of (column≥’2022–05–25' and column<’2022–05–26') which uses indexes.
Summary
Laravel offers a lot of functionality out of the box, but you must use it with caution, understand what is doing internally, check the performance, and don’t trust too much in magic solutions.
