Micro vs Micro Collection: Performance

I recommend using full application if you gonna have so big application, maybe multi-modules ? Or just use lazy loading and micro collection and therew will be no difference.

Don't care about performance until it will slow down.

Lazy loading with Micro app is just fine for such use case. Keep in mind that you might miss some features (i.e. if you want to put some constraints on your routes/handlers, or to use conversors you'll have to override default MicroCollection).

Concrete example follows, I use this since I always tend to use lazy loading, so I don't want to specify it per handler:

class MicroCollection extends \Phalcon\Mvc\Micro\Collection
{
    function setHandler($handler = null, $lazy = true)
    {
        //Inject current namespace and normally proceed further treatment of request to a parent method
        return parent::{__FUNCTION__}(__NAMESPACE__ . '\\' . $handler, $lazy);
    }
}

I do not want to use the full because the performance is not what I want. Look at this link: https://www.techempower.com/benchmarks/#section=data-r12&hw=peak&test=db&l=27wq9r

Micro is x5 more fast.

I recommend using full application if you gonna have so big application, maybe multi-modules ? Or just use lazy loading and micro collection and therew will be no difference.

Don't care about performance until it will slow down.

This is because micro is using raw db, like pdo, not phql and models and is also smaller.

https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/PHP/phalcon/app/controllers/BenchController.php https://github.com/TechEmpower/FrameworkBenchmarks/blob/master/frameworks/PHP/phalcon-micro/public/index.php

Are you gonna have 60k requests per second ?

I've got a Micro app with just less than 400 mapped routes (Lazily loading controllers), using collections and the slowest part of the Application handling is the route matching - When I say slow I mean ~50% of the entire execution time was attempting to match the route patterns.

The way I got around this was to:

• A. Use 'namespaces' in a way, categorising each route first prefix with a directory name - and correlating which routes to only load based on that
• B. Use the cache service to cache the mapped Route ID based on the HTTP Method and URL that is trying to be mapped to aid the route matching process

Store routes in Database.

It would be faster or not?

Technically no - memory is always going to be faster.

Even if they were stored in a DB, you would still have to map/load them into memory and let the application handle/match which route to use so you'd just be adding an extra layer with almost no benefit

you're right.

Drupal Store routes in DB <- slow Magento, also. <- very slow.

Drupal?! xD Magento(2.x) is a 1st class crap, and almost any approach they took is wrong. Routes (if you have lots of them) should be stored in memory (i.e. memcached), that's the only resonable solution for such use cases.

Anyone can give an example of caching routes?. (Code Example). I'll try to do it, but if someone wants to share his magnificent code. your welcome.

Why you even want to cache them ? Don't cahce them, just use opcache, it's enough, you won't any more speed boost from caching routes as objects and unserializing them. Anything more will need some serializing/desarializing things which can actually slow down this. Better to cache response from them, like not make db queries and other stuff like rendering etc.

It will be slow only after first page load with opcache, after next loades any implementation of caching routes stuff will be like max 10% performance gain IF ANY, it might be even slower, just don't waste time on things like this, IF IT WILL BE SLOW, THEN WASTE TIME.

It can be said that micro Phalcon without collections is faster?. I would like to do a little test with 100 200 300 400 500 routes. and I tell them.

Even it will be than it will be harder to manage... like code will be shit. Its obvious it will be faster because no object, no method calls etc. But is worth it ? Surely not.

I can separate routes in different files.

- app
- modules
    - user
        - user.routing.php
    - system
        - system.routing.php
    - config
        - config.routing.php
    - ...
- web
    - index.php

and in index.php:

// ...
        /**
         * Include Application
         */
        foreach ($app->config->modules as $module => $config) {
            if ($config['active'] == true) {
                include APP_PATH . '/modules/' . $module . '/' . $module . '.routing.php';
            }
        }

// ....

Include 20 files, It is faster than using collections. ¿¿??

Yes it will be faster but this is overall bad solution.

As i already told above - if there will be any slowdown - then find a solution to it. Don't care about it if there is not yey slowdown. Read this:

https://c2.com/cgi/wiki?PrematureOptimization

Just basically:

Make it work.
Make it right.
Make it fast.

The second thing here is most important.

@xerron: I don't understand why you are so focused on routes in particular? Just go ahead and develop your app and test it. Surely routes will be your least problem.

@stamster @Wojciech thank you. They are right. I am now using Micro without collections and works and goes very well, but the code is not very maintainable, my concern is that after passing it to collections, my application does not fall much in performance.