Love Fuel?    Donate

FuelPHP Forums

Ask your question about FuelPHP in the appropriate forum, or help others by answering their questions.
Reflexion on when to use ORM and when not to
  • Hi guys,

    The Fuel ORM is quite performant for what I know, but it's still an ORM, leading to more server load. What I don't know is how exactly more ressources it will consume. Of course, you would say, it depends a lot of what you are building.

    But, i'm quite the performance paranoid guy. Thoses last years with Fuel, I ended up using the ORM only for the queries where you handle a single model instance with relateds model logic, and the DB class when I have operations to do on several entries.

    At my compagny we have a quite big website on fuel and I wanted to have advices from peoples who use Fuel on big websites where performance optimisation matter, and what strategy you have for ORM

    Thanks
  • HarroHarro
    Accepted Answer
    If you profile the ORM, the biggest difference in performance (as in 80-90%) between ORM and DB is the hydration into ORM objects. The exact figure depends a bit on the PHP version used, the ORM is relatively faster in 7.x than it is in 5.x. The code in itself is pretty effficient.

    We use the ORM for CRUD and list/paginate operations, where relations may be important, but there is never a volume. For volume operations, tasks and batch or bulk changes, we always use DB, not only for performance, but also because you can construct the exact query you need, which might improve efficiency and performance even more.

    Also, there is a common misconception that using Models (in the MVC meaning) means using ORM models. This is not the case.

    We use traditional models that deal with data domains (and not single tables), these models have methods that may or may not use ORM models to retrieve data. Sometimes they even use DB calls that return populated ORM models ( using as_object() ).

    For example, we could have a model "Account" that internally would deal with ORM models users, groups, rights, and so on.

    And, keep into account that by default the ORM caches its objects, so selecting 10.000 rows with 7 joins would see your process memory evaporate in front of you, which in turn has an impact on hardware specs/sizing and concurrent processes, and ultimately also in (percieved) performance.
  • Make sense. Thanks you.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

In this Discussion