Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MsgPack as separate project #108

Open
ghost opened this issue Nov 15, 2016 · 4 comments
Open

MsgPack as separate project #108

ghost opened this issue Nov 15, 2016 · 4 comments
Assignees
Labels
question Further information is requested
Milestone

Comments

@ghost
Copy link

ghost commented Nov 15, 2016

Hi,

  1. Thank you for amazing work.
  2. Your binary protocol is based on MessagePack but it is hardcoded in "tarantool-php" ext, I suggest to move it to a separate PECL ext, I understand that this is out of scope of this project, but I think it will help community. Official php msgpack extension is very buggy and seam that has been abandoned only a good alternative is rybakit/msgpack.php but it is written in Pure PHP and is less performance (after some tests with big data)
@bigbes
Copy link
Contributor

bigbes commented Nov 15, 2016

Thank you, @umbri. It's nice to hear.

But I'd planned to move from my own MsgPack implementation to https://github.com/msgpack/msgpack-php before. Why do you think it's buggy?

@bigbes bigbes added the question Further information is requested label Nov 15, 2016
@bigbes bigbes self-assigned this Nov 15, 2016
@ghost
Copy link
Author

ghost commented Nov 15, 2016

@bigbes,
Here: issue #105 and Here issue #107
And this is only what I found, more then that, I write this issues and no response, and my pull request as well is ignored, pull #106,
I changed only README and travis fail :(

There are some very useful features that was proposed by @rybakit feature and others ~ 1 year ago, and no changes

I hope this message will inspire you to do a right move :)

@rybakit
Copy link
Collaborator

rybakit commented Nov 15, 2016

I would like to switch to msgpack/msgpack-php as well. Imho, extracting msgpack from tarantool-php to a separate extension will not solve anything, as it has more or less the same problems - no bin/str/ext/streaming/object packing support (correct me if I'm wrong).

I was more thinking about injecting a custom msgpack handler by implementing an interface, like it's done for example for php sessions: http://php.net/manual/en/class.sessionhandlerinterface.php.
So a user can choose if he/she wants to use the default msgpack library or a different one. I did it for the pure php client, but I don't know how useful this feature will be for the tarantool-php extension.

it is written in Pure PHP and is less performance (after some tests with big data)

@umbri Can you share your benchmarks? In a real life app you will not notice any difference except you are working with very large arrays/strings and doing millions of iterations in a loop or using php < 7.0 ;) In some edge cases the pure version even outperforms the pecl extension.

@ghost
Copy link
Author

ghost commented Nov 15, 2016

@rybakit

  1. Thank you for your work.

  2. The main problem is that msgpack/msgpack-php is not supported, there are many good proposal how to improve it, even README is useless, I looked in tests to find streaming features, as this was the main argument to choose Message Pack. So if someone can rewrite it, I will be happy to help them/him.

  3. I run some tests (synthetic) with json, pecl MsgPack, @rybakit MsgPack, with php 7.0.12, on small data ~ same results, on big data ~400% on @rybakit MsgPack, but json was ~11000% (sorry about few details, maybe one day I will share Tests, need some cleaning)

  4. I plan in few weeks to start using @rybakit MsgPack in production, and i will have real world stats.

  5. Thank you for @rybakit MsgPack 👍

@Totktonada Totktonada added this to the wishlist milestone Mar 23, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants