Refactor packet reading/writing
Closed this issue · 9 comments
AGAIN WITH THE REFACTORING. I know this has been rewritten almost three times now.. but the string concatenation and multiple function calls to parse a packet is really wasteful and SLOW. We should be doing one pack statement, and one unpack statement. Easy.
Except we'll have to redo every packet that's been written so far. 👎
Example: http://systemsarchitect.net/parsing-binary-data-in-php-on-an-example-with-the-pcap-format/
UPDATE:
fyi, the new internal reading architecture should be client agnostic. The packet buffer should be Stackables in which pthread workers can chew on. We should probably do the same for outgoing clientbound packets, but I don't think that will be too much of a perf increase.
UPDATE 2:
check for inspiration at https://github.com/Poweruser/MinetickMod
pthreads?
I've been looking at pthreads, I want to try it out but I don't know how hard it would be to integrate and what the right structure would look like. I think maybe the client should have it's own packet processing thread, and that would be a good setup. But I have never touched multithreading before, it's interesting but daunting..
EDIT: forget it. We're doing pthreads somewhere, for learning experience. I wonder how this is going to work with ReactPHP's event loop.
I would guess there would be a fair bit of pain involved in getting pthreads operational in such a large project. But there looks to be a lot of pain refactoring what you already have (not a criticism, just an observation of the size of project you are working on).
You would want to look at pthreads in PHP 7, as the support is looking much more mature, and thread safety appears to be managed much better.
Honestly, I don't care much about rewriting code, I enjoy the refactoring process. 😀 This'll be interesting. I'll spend some time researching and seeing how other people incorporated it, or for some basic multithreaded concepts/structures before jumping into it. If you have any good resources, feel free to send them my way. 👍
I think the krakjoe repo is the benchmark for pthreads, and would be the place to start if you wanted to head down that rabbit hole.
Are you already hitting performance issues? Is this why you are looking to refactor?
I'm hitting performance issues now, and I'm pretty sure the bottleneck is my packet reading implementation. I'll do some perf profiling, but it definitely is blocking the main thread and delays incoming packets from being read. I believe I have a better solution in my head for it.
I wonder how much impact Logging is having on performance. If the logs are also being committed to the filesystem, the thread will have to wait for the I/O to complete - which on a single threaded program will slow everything down significantly.
Have you tried disabling logging?
Logging would be a perfect candidate for pthreads. From memory you are using Monolog, which means implementation would be dead simple.
That's a really easy one to get added. I've switched to using PHP 7.0 RC1 version and got pthreads working, but the event library hasn't been ported to PHP 7 yet. Which kinda brings 7.0 to a halt for now.
I'm trying to look at some other multithreaded architectures. It's very confusing since I've only done work in node.js, and the async/callback architecture makes it hard to think. There's also no documentation for the new pthreads v3 api currently as well.
Fortunately there was a guy who added server multithreading to parts of Minecraft, and I got a few ideas on how to approach bringing parallelism to several parts of the server: https://github.com/Poweruser/MinetickMod
Lots of ideas! Lots of stuff to do! 🎉
I think it's good to go for now. I don't think it's necessary to integrate Pthreads yet. I've seen good performance so far, surprisingly.