Welcome Guest, Not a member yet? Register   Sign In
Long-living PHP support (Swoole/RoadRunner etc)
#11

(12-25-2022, 08:59 AM)ruslan Wrote: The question is does CI need to support Swoole, RoadRunner, etc
What for? Performance?
99% of performance problems are caused by bad application code, not by Nginx + PHP-FPM
CI is fast and loved because of its simplicity. This gives him power and strength. Let's leave it at that. Otherwise, it will become a big lazy monster like Laravel.

Thank you for your opinion.
Probably we all agree that simplicity of CI is important.

My opinion is of course everybody does not need to use Swoole, RoadRunner,
but if CI runs on them easily, it would be better.
Now CI does not work on them at all.

Mainly because the current CI is not well-designed. So I want to improve CI design.

It may be true 99% of performance problems are caused by bad application code,
but CI4 is much slower than CI3 comparing with "Hello World!" benchmarking.

And this topic is mainly on internal design or framework code of CI4.

I don't know what do you exactly mean by "a big lazy monster",
But everyone here also don't like such a thing.
Reply
#12

(This post was last modified: 12-27-2022, 12:49 AM by ruslan.)

(12-27-2022, 12:24 AM)kenjis Wrote: I don't know what do you exactly mean by "a big lazy monster",

If you throw an Exception at the very start of some Controller in CI you will see stack trace of 4 (four) function calls initiated from index.php
In Laravel there will be 40+ calls with many 3-rd party libraries involved (mostly from Simphony)
I actually use only `routing` service of the backend framework and my request goes through 40+ other code blocks. That's unreasonable for me and that's regarding `big`
Why Laravel is `lazy` can be seen in benchmarks
Also development speed on CI is much faster than on Laravel


I'm not opposed to CI improving its architecture, but there must be a measure and a reason for everything.
It could turn out that the changes required to support Swoole will attract 5% of new users, but bring a bad experience to 50% of existing ones
Like the case you mentioned when CI3 to CI4 got slower with "Hello world" benchmarking. Wasn't it just a not needed database connection openning btw?
Reply
#13

(12-27-2022, 12:49 AM)ruslan Wrote: If you throw an Exception at the very start of some Controller in CI you will see stack trace of 4 (four) function calls initiated from index.php
In Laravel there will be 40+ calls with many 3-rd party libraries involved (mostly from Simphony)
I actually use only `routing` service of the backend framework and my request goes through 40+ other code blocks. That's unreasonable for me and that's regarding `big`
Why Laravel is `lazy` can be seen in benchmarks
Also development speed on CI is much faster than on Laravel

Thank you for the clear explanation.
I got what you mean!
Reply
#14

(12-27-2022, 12:49 AM)ruslan Wrote: Wasn't it just a not needed database connection openning btw?

No. Ci4 does not connect to database by default.

It is not too big like Laravel, but CI4 is bigger or having more functionality than CI3.
And that makes CI4 slower.

Of course, just returning "Hello World!" is a very small part of the process compared to the totality of normal application processing.
So it does not mean CI4 apps are much slower than CI3 apps.
But I guess CI4 apps are not faster than CI3 apps now.
Reply
#15

Quote:The question is does CI need to support Swoole, RoadRunner, etc What for? Performance?
Performance is a major key. Even PHP version updates consist of performance improvement.

Further, performance isn't the only reason. Swoole or similar servers offer features like WebSockets, asynchronous programming, coroutines, and microsecond cronjobs that are not available with traditional NGINX or Apache servers.

Quote:Let's leave it at that. Otherwise, it will become a big lazy monster like Laravel.


I guess there is a misunderstanding regarding if CI supports long-living applications. Laravel is slow because 3-rd party libraries are involved. WordPress CMS is slow because of the availability of plenty of plugins and themes for it.

Here the concern is about designing CodeIgniter in a better manner that would support those servers as well. For example, removing usages of superglobals, and static variables from its core. Simplicity and speed will remain in their place or even will improve.


Quote:It could turn out that the changes required to support Swoole will attract 5% of new users, but bring a bad experience to 50% of existing ones

It won't turn out. I'm a person who is using OpenSwoole for a live project and I'm extremely thankful to the CI team and @monkenWu. I had started the project (2nd version) with CI4 in PHP-FPM. And even in that case, I was not happy as it was performing slower than CI3. (The original project was written in CI3 and is now being recreated with CI4, then after OpenSwoole replaced Apache).

From my experience, I can say that incorporating such changes won't impact those 50%. It is about design patterns that are causing blocks from intended use as well as leveraging their full potential, not about including a feature with X library. Also, the development speed would remain faster because theoretically, we are writing application code in the same manner from CI2 to CI4 while there has been a lot of change among these three.


Quote:99% of performance problems are caused by bad application code.
As it is. If CI changes its architecture to support non-traditional servers or to reduce performance difference between CI 4/3, ultimately, it will depend on the application developer to write good application code.

CI allowed importing various namespaces and packages. Why shouldn't it support non-traditional servers? Even PHP has an official extension for Swoole. If a framework won't support a server, where else an end-developer would go?
Reply




Theme © iAndrew 2016 - Forum software by © MyBB