[Redis] Perl Redis Client news

[Damien Krotkine]

You're welcome.



No I'm looking for people able to test on windows. Anyone ?





On Mon, Nov 18, 2013, at 03:39 AM, Pedro Melo wrote:

Hi,

On Mon, Nov 18, 2013 at 1:11 AM, Damien Krotkine
<[1]damien at krotkine.com> wrote:

In the past weeks, you may have seen that I've released 1.962, 1.963
and

1.964. These release had 3 goals:



- do a first release as new maintainer

- perform some fixes due to maintainership change

- try to get rid of easy-to-fix issues



These goals have been met, so I'm happy. Redis is now fork-safe, and
has

better documentation and some minor issues fixed.


I've updated my servers to use it, and so far so good!

Thanks for you hard work on this…


Now, comes the next part of the Plan: tackle the serious issues about

Redis.pm



- sysread vs read vs recv: Ivan and myself have started brainstorming

and working on getting read of mixing sysread and read on windows, and

doing more benchmark to see if read is really faster.


the decision to go with read was not about "reading" speed but "read
until \r\n" speed. The PerlIO layer was *much* faster that whatever I
could find at finding the \r\n that Redis protocol uses to limit the
size frame, that's why I complicated the design…

My gut feeling is this:

 1. make it right by default;
 2. make it fast by user option.

What this means is that a pure sysread based solution is much easier to
get right and should be our best default on both UNIX and Windows.

Then, we can have specialized modules that can give us more performance
if they are present/installed: the read-based code as a PP solution, or
XS-based Redis protocol parsers, or even integration with hiredis.

The way I was thinking about this to do this is to extract all the
network code (expect the connect stuff) into a small lib with one   API
(you can even use a CodeRef as your API, don't need a full object):
read next command. It should accept a timeout (0 wait forever, > 0 wait
X seconds (fractional), < 0 non-blocking read), and return undef or a
structure representing the command.

I *think* you only need that command, but error reporting will be
crucial to keep the current re-connect logic in place.


- pubsub failing at surviving a server restart (

[2]https://github.com/PerlRedis/perl-redis/issues/34 ): that issue
should

be fixed in master, I'll send an email about it tomorrow.


Saw your fix, looks good, but I only casually glanced at it.


- pipelining: currently, this is the major issue, as pipelining doesn't

do what it's supposed to do (see issues 45, 46 and 49). However we know

how to fix it, so it should be done rather quickly.


When this was recently reported to me, I though it was about Naggle,
but I didn't investigate the issue further at the time.

Bye,
--
Pedro Melo
@pedromelo
[3]http://www.simplicidade.org/
[4]xmpp:melo at simplicidade.org
mailto:[5]melo at simplicidade.org

References

1. mailto:damien at krotkine.com
2. https://github.com/PerlRedis/perl-redis/issues/34
3. http://www.simplicidade.org/
4. mailto:xmpp%3Amelo at simplicidade.org
5. mailto:melo at simplicidade.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.scsys.co.uk/pipermail/redis/attachments/20131118/8cd1526b/attachment.htm