Improve Ecotone performance

[jlabedo]

So let me present my thoughts on performance improvement.

Here is a screenshot of an xdebug profile of ecotone lite "PlaceOrder" benchmark in production, with 100 iterations to avoid autoloader impact, and opcache disabled. The bootstraping of the messaging system is 63%, the execution of the test case is 36% of the time. Fail fast is disabled, so some messaging components are also built during execution.

I see mainly three ways of improving performance

Messaging system resolution

I will take for example the gateway proxy builder that is one of the most time consuming component in the profile (36%).
Looking at the code, a lot of resolutions are taken during build: resolving gateway converters, resolve annotations, sort interceptors, add an interceptor for error channel. A lot of this could be resolved during preparation phase and be cached.

Opcache and messaging system serialization

In one of my previous tests, I tried to export the messaging system configuration as a php file instead of serializing it. The performance gain was more or less 50% with opcache enabled, which should be the case for http requests.

Lazy component creation

Some components are not lazy: for instance all gateways are created on each boot.

[jlabedo]

Solution 1: resolve all messaging components during preparation phase for caching

During preparation phase, builders (GatewayProxyBuilder for example) could be compiled to resolve all they can, like interceptors, parameter converters, gateway converters, annotations, ... We could add this interface that a builder could implement. :

interface CompilableBuilder {
  public function compile(ReferenceSearchService $referenceSearchService, ChannelResolver $channelResolver): void;
}

After "compilation", builders should be locked for changes and immutable.
During the execution phase, a typical implementation of a builder would be:

class GatewayProxyBuilder implements InterceptedEndpoint, CompilableBuilder
{
//...
  public function build(ReferenceSearchService $referenceSearchService, ChannelResolver $channelResolver) {
    $interfaceToCall = $interfaceToCallRegistry->getFor($this->interfaceName, $this->methodName);
    if ($this->isCompiled) {
      return new Gateway(
        $interfaceToCall,
        new MethodCallToMessageConverter(
            $interfaceToCall,
            $this->methodArgumentConverters
        ),
        $this->messageConverters,
        new GatewayReplyConverter(
            $referenceSearchService->get(ConversionService::REFERENCE_NAME),
            $interfaceToCall,
            $this->messageConverters,
        ),
        $this->buildGatewayInternalHandler($interfaceToCall, $referenceSearchService, $channelResolver)
      );
    } else {
      // ...
    }
  }
}

This solution would help only on "Messaging system resolution" performance.

[jlabedo]

Solution 2: dump a messaging system into a container

Continuing on solution 1, we could think of the MessagingSystemConfiguration like a ContainerBuilder and the MessagingSystem like a Container of messaging components. The Messaging configuration and all components builder could return definitions of messaging system components, like in php-di or symfony. Here is an example:

class GatewayProxyBuilder implements InterceptedEndpoint, CompilableBuilder
{
//...
  public function build(ReferenceSearchService $referenceSearchService, ChannelResolver $channelResolver) {
    $interfaceToCallReference = new InterfaceToCallReference($this->interfaceName, $this->methodName)
    // All resolutions can be done during this phase
    // And then dumped into "definitions"
    return new Definition(Gateway::class, [
      $interfaceToCallReference,
      new Definition(MethodCallToMessageConverter::class, [
          $interfaceToCallReference,
          array_map($this->methodArgumentConverters, ($converter) => $converter->build())
      ]),
      ...
    );
  }
}

With these definitions, we would be able to dump all messaging system components into an highly performant php container. With this solution, we would have:

• improved messaging system resolutions. Everything would be resolved during preparation phase.
• opcache optimization: container implementation can dump a container to a php file, so opcache can optimize the code.
• lazy creation: container implementations have lazy creation built in

A proof of concept is #223.

[dgafka]

@jlabedo I would like to see the profiler results after latest changes on 1.107.1. This does fixes the problem with to early constructed gateways and optimize the way we create proxies. This solution still needs some optimalization phase, as right now building checks are ran on first execution.

I've not yet invested much time into the POC, but I understood the idea. I wonder about what will be performance gains now with the above optimalizations. Is this something you can verify early or we need to wait for POC to be finished to see the benchmarks?

[jlabedo]

I understand your concern about integrating with external integration process (and I knew you would have this concern :) ). As you can see, it is relatively small and dumb to integrate with Symfony or php-di. For Laravel I don't know (help would be very welcomed).

I agree that depending on different frameworks for mission critical components seems dangerous, as it can result in "it works on Symfony but not in Laravel", or "it works with Symfony 6 but not with Symfony 7". But:

• there is less code to maintain
• framework container implementations are mature and stable
• the responsibility of the framework is small, it's only instantiation.

Moreover, if we decide to return to a single container implementation for all frameworks for some reason, it won't change a lot.

[dgafka]

Yea, I can see it's small integration surface.
So let's proceed with the idea of framework specific implementations of the containers.
About Laravel, I believe it use Symfony DI under the hood. We can verify that at the end of implementation and right now focus on Ecotone Lite and Symfony.

[jlabedo]

Great, thanks for your review, you spotted the interesting parts.

[jlabedo]

@dgafka , do you agree with the one big refactoring without progressive refactoring ?

[dgafka]

Yea I agree @jlabedo. I can see it will be easier to prepare everything at once and just fix the code along the way, than try to make a split now (not even sure what splits we would apply here). Better to put energy into finishing and testing this up.
We've high test coverage for the business functionality, so if we manage to pass tests, we've high assurance that it simply works.