[2nd try] PHP client question: why socket_create()?

[Ryan T. Dean]

--fckbADODYWZD5TdN
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Oct 06, 2003 at 10:39:47AM -0400, Justin Matlock wrote:
> Because when the first client was written, streams didn't work properly, =
and
> I think Ryan (the original author) was just trying to get a version out t=
hat
> worked, and not deal with the funky PHP bugs that existed then...

I guess I'm a little confused.  I've got code written for 4.1 that uses=20
fsockopen().  Granted the newer stream_* functions came with 4.3.0, but=20
you could still control blocking and everything via the=20
socket_set_blocking, socket_set_timeout and socket_get_status (which are=20
now just wrappers for the new stream_* functions).
 =20
In any case, I received a request to 'update' the PHP client.  While I =20
had been planning on writing my own client anyway sometime next week for=20
inclusion in a project of my own, the request stated that a number of  =20
people are having problems with the current client, so instead I stayed=20
up all night last night reporting the Perl client to PHP.
 =20
The port is a direct port, because I wanted to get it done.  Ever have =20
something just grab onto you and you couldn't stop thinking about it?  =20
This happened to me last night.    =20
 =20
In any case, I'm using (p)fsockopen - my implementation works on 4.3.3 =20
and 4.3.4.rc1.  To use the persistant version, when initializing the   =20
object add a 'persistant' key to the args array with a value of true.

My only outstanding bug is in run_command - which the current PHP client=20
doesn't even support.  run_command is supposed to return an array of=20
strings, each string being a single line as read from the server. =20
Strangely, fgets() (at least on FreeBSD) modifies the linebreak from=20
\r\n to just \n.  fread() doesn't have this broken behaviour, but the=20
resulting logic to turn fread() data into an array of strings gets a=20
little ugly when you have to cosider that you may have stopped a read=20
mid-string.  Alternatively, each line after its read I could check to=20
to see if \r\n is present at the end of the line, and if not, to rtrim()=20
the current line and append a \r\n.  Each has its merits - but=20
run_command does work now, if your program doesn't have a dependancy on=20
the \r\n at the end of every string in the array.

I suspect the client may be a little slow retrieving keys yet; using get=20
on a valid key with 36 bytes of data takes around 0.095 seconds on my=20
test box (a 380mhz amd k62 with 192mb of memory).  get_multi on three=20
keys (said 36 byte block plus two different values I've been=20
incr/decring) takes around 0.103 seconds.  This may be normal delay;=20
I'll have to go through and profile _load_items and see where the delay=20
is.

Please note that this is a direct, get-it-done port.  It doesn't yet   =20
take advantage of PEAR's error handling yet.  It will eventually.  Right=20
now, false and null indicate failure, while true and/or a value indicate=20
success - just like the Perl client. =20

All this having been said, the client is currently available at=20
http://www.cytherianage.net/~rtdean/memcached-client-php-0.1.tar.gz.

I would appreciate any help in testing it.  If you can break it, I'd=20
like to know how; if its slow doing something, tell me what you are=20
trying to do.

                -Ryan T. Dean

PS- As a side note, the original reasoning behind writing my own client=20
was for my new module framework which I've been developing/using for my=20
own PHP projects, which are mainly content management systems.  I was  =20
also planning on working it into Cache in PEAR.

PPS- Testing on 4.3.4.rc1 was done using my very basic testsuite which=20
hits all the big functionality: add, replace, set, get, get_multi, incr,=20
decr, delete.  Testing is done with small, medium, and large sized data=20
blocks.

--fckbADODYWZD5TdN
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/gdSRW6VZzwycJGURAlyxAKCFcMqOsyA5LzGKYr/DQ9/RbVFNJwCgwSob
ZR1qUD2lMtXz6Ww06jD/hsQ=
=QIVn
-----END PGP SIGNATURE-----

--fckbADODYWZD5TdN--