Use Swoole coro without changing event loop

[cayolblake]

Hi @walkor

I understand that to use Swoole's coro I have to set using Swoole's event loop.

I do not want that, just Workerman while still using Swoole's coro, while benefiting for Workerman's extra %15 of being leightweight and further enhancements.

How to do so?

Any alternative for having similar behavior without using Swoole may be?

All what's needed is running non-blocking PHP code, and getting back the results. That's it.

[walkor]

At present, swoole collaboration is the most feasible solution in PHP, and there is no good alternative.

[cayolblake]

Not even the newly born Fibers?

[walkor]

Fiber cannot be well used at present, because most libraries and PHP extensions do not support fiber.

[rentstack]

You can use, i was write own async mysql client based on Fiber, but this is private repository.

[cayolblake]

@rentstack any hints on that? code samples?

@walkor is the strength and enhanced performance in workerman come from the internal eventloop used or the code is fast? Since workerman is at least %20 faster than Swoole!

[rentstack]

@cayolblake You need to make another the event loop that runs all registered fibers.

[walkor]

It is recommended not to waste time on fiber. Using fiber means that you need to rewrite all clients (MySQL redis, etc.) in PHP. Obviously, the performance of the client implemented with PHP will be much lower than that of the PHP extension. Through the stress test, you will find that the extreme performance will be greatly reduced after using fiber than using extension. If you like coroutines, swoole is the best solution at present. In addition, coroutines programming is somewhat complicated, and it is easy to get bugs without experience. If you are interested in PHP coroutines, it is recommended to directly use the swoole coroutine framework, such as hyperf.

[rentstack]

@walkor I have tested all mysql clients for workerman and this is faster then any other and also it works great with your Redis and Http clients. The only thing i didn't use libevent and don't know this work with him.

[cayolblake]

@walkor

I don't understand, why do you recommend against the official PHP implementation of fiber?

Also, do you mean Swoole or OpenSwoole? 🤔

I understand that you might not want to answer why workerman is faster than Swoole, yet, that's the fact that everybody knows and experiences, so, it seems that if everything is running within the PHP space it looks to be faster than talking to external C/C++ functional whom is managing the memory on their own. That's at least for the ones building microservices doing a simple/small specific job and get to feel the unjustified performance difference.

Our organization took the decision not to use anything related to Swoole after the fist-fight between the developers and the take-over by Bruce and the bad-mouth-words fight and childish behavior between the whole team affecting all the user base all-over the world and causing extreme confusion caused by the rebranding and now we have Swoole and OpenSwoole.

Come on, nobody building anything reliable would trust Swoole in any way after all of that.

Correct me if I'm wrong please.

[walkor]

I don't understand, why do you recommend against the official PHP implementation of fiber?

Maybe my reply is ambiguous. From your previous issue, you have very high performance requirements. The reason why I do not recommend you to use fiber is that fiber may not meet your expected performance requirements, because using fiber means that you need to use PHP to implement many clients. For example, to implement a MySQL client, you need to use PHP to parse the MySQL protocol. The performance of the PHP parsing protocol is far inferior to that of the pdo_mysql using C. So the final result is that after using fiber, the ultimate performance may not meet your expectations. In addition. in addition you should also consider using fiber to implement some functions to replace such as file_get_ contents file_put_contents fread fwrite curl and other functions with blocking behavior. I'm not sure if you have time to do all of that.

Finally, if you using fiber, your programming habits need to be changed accordingly. For example, you should consider that the concurrent operation of fiber causes global variable pollution, and that you cannot use the same MySQL or redis connection resource between fibers at the same time. Therefore, you need to implement connection pooling.

Based on the above point of view, I do not recommend that you use fiber. Of course, if the above will not cause difficulties for you and accept some performance losses, fiber is a good solution.

As for why the performance of the workman stress test is higher than that of the swoole, I can't give a clear answer, because I don't know the internal implementation of the swoole, nor have I seen the codes of the swoole. I guess the reason is that the internal functions of swoole are too complex. For example, the creation and destruction of collaboration processes affect the performance of swoole. In addition, it seems that the HTTP protocol resolution of swoole is not fast enough.

Finally, I like the fiber feature of php8 very much, and I urgently hope that the fiber ecosystem of PHP can flourish quickly. Workman V5 also needs fiber ecology.

[cayolblake]

Thank you @walkor for the detailed reply.

I do understand your point and appreciate your detailed explanation.

I totally agree with you that having to implement for example the MySQL client protocol in pure PHP would introduce an overhead, take a lot of time, and be prone to never-ending issues. But, I have a weird feeling the overhead could be very small or even none, given you're using the new JIT optimizations.

Swoole is definitely the most mature and widely-used solution available, but, its performance gets lower and lower by every release I don't know why, and this defies the reason behind its existence.

For example, there's now https://github.com/swow/swow which I believe is developed by the same core developer of the original old-school Swoole.

Swow, for some weird reason also, gives even faster outcome than Swoole and workerman. Its HTTP server is faster than Swoole by ~3x, and faster than workerman by ~1.7x

Perhaps it needs to be checked by you and see if using its event loop can benefit workerman in anyway, performance/stability wise.

[walkor]

Okay, thanks for your post. I'll keep eyes on swow.

[cayolblake]

Thanks @walkor

You are always from/with the community and your contribution is beyond outstanding and always appreciated, big time ❤️

It would be great if you could write some sort of a blog or even a wiki on analyzing why/how workerman achieves such performance and internal architectural decisions involved.

[walkor]

I don't have a blog or wiki. In general, the secret to improving the performance of the framework is to make the framework as simple as possible. The less code a request executes, the faster it is.