Brad-
I notice you don't link to any PHP APIs from the site (and I believe you used to). I'm sure you're aware of it, but if not, there is a PECL memcached extension that can be compiled into PHP 4.3.3+.
http://us3.php.net/memcache
I am using this and it works great. I'm not sure if the "best" PHP API is some topic of hot debate or not, I assume there must have been some problem or the links wouldn't have been pulled.
Anyway, my vote is for this, an actual PHP extension. To me, this seems the most formal, recognized effort to bring memcached to the PHP environment.
Just my $0.02
Joel

Joel Lee wrote:

http://us3.php.net/memcache

I am using this and it works great. I'm not sure if the "best" PHP
API is some topic of hot debate or not, I assume there must have been
some problem or the links wouldn't have been pulled.

Anyway, my vote is for this, an actual PHP extension. To me, this
seems the most formal, recognized effort to bring memcached to the PHP
environment.

The main issue with that extension is that it doesn't have built-in
multi-server support. The "mcache"
(http://www.klir.com/~johnm/php-mcache/) extension is better
feature-wise, and it's also based on the fairly widely-used libmemcache.

Having said that, we do use that extension at the moment, with our own
multi-server wrapper class around it. We're trying to move to the mcache
extension currently.

Russ

I use the pecl extension and have never used the other extension but I
can see multi-server support as a good thing.

Just because it has multi-server support doesn't mean you HAVE to use
it, you could still do as you suggest.

The great thing about having multiserver support is you don't have to
manage it, Also I would suspect it has built in failover If one server
goes down it starts using the others right away, Programming that on the
PHP side while possible just doesn't make sense if you don't have to.

Richard Thomas - CE
Cyberlot Technologies Group Inc.
507.398.4124 - Voice

Antony Dovgal wrote:

04.09.2005 16:26, Russ Garrett wrote:
>
>Joel Lee wrote:
>>
>>
>http://us3.php.net/memcache
>>I am using this and it works great. I'm not sure if the
"best" PHP >API is some topic of hot debate or not, I assume there
must have been >some problem or the links wouldn't have been
pulled. >>Anyway, my vote is for this, an actual PHP
extension. To me, this >seems the most formal, recognized effort
to bring memcached to the PHP >environment.
>>
>The main issue with that extension is that it doesn't have
>built-in multi-server support.
>
>
Not precisely true.

See this pseudo-code:
<?php

$first_server = new Memcache();
$second_server = new Memcache();
$third_server = new Memcache();
$fourth_server = new Memcache();

?>

Nothing prevents you from using as much servers as you want in the
same time.

I'm a strong believer that it's better to write couple of lines in PHP
and have 100% flexible API then to hardcode some logics into the
extension and have to work around it every time to get the desired
behaviour.
>
>>The "mcache" (http://www.klir.com/~johnm/php-mcache/) extension is
>better feature-wise, and it's also based on the fairly widely-used
>libmemcache.
>
>
I'm just curious: besides this "multi-serverness" what are the
additional features it offers?
Comparing to http://php.net/memcache, of course.

Thanks.

6 Sep 2005, at 13:18, Antony Dovgal wrote:

Not precisely true.

See this pseudo-code:
<?php

$first_server = new Memcache();
$second_server = new Memcache();
$third_server = new Memcache();
$fourth_server = new Memcache();

?>

Nothing prevents you from using as much servers as you want in the
same time.

I'm a strong believer that it's better to write couple of lines in
PHP and have 100% flexible API then to hardcode some logics into
the extension and have to work around it every time to get the
desired behaviour.

This is what we do at the moment, but the main issue with this is
that there's no failover. In order to implement proper failover you'd
need to detect when a server has died and record that fact in shared
memory (which PHP doesn't have reliably, which is why we're using
memcached in the first place), so you don't have to attempt to
connect to a dead server every time. This is a big pain.

We don't do proper failover at present (if one of our web nodes dies,
our site is unusable), which is why we were looking to use the mcache
extension to implement it.

Russ Garrett
russ (AT) last (DOT) fm

Hi Russ ;)

Very short timeouts and machine local status tables (in memcached /
turckmmcache / eaccelerator / whatever you want ) seem to produce
pretty reliable fail over for us. Throw in some timeout's and
register_shutdown_functions()s to recheck the server periodically and
it actually starts to get pretty nice.

As long as your connect() time-out is low enough to merely make it
look like the page took slightly longer than normal to load, you
shouldn't have anything to worry about. It means you have a higher
potential for false positives but we haven't had any of those yet
with our time-out set to 500 ms.

Even if you use something which has a habit of forgetting about keys
(e.g. turck) it's not too painful as the failed connection attempt
ratio still tends to stay low enough to not be particularly noticeable.

6 Sep 2005, at 14:12, Russell Garrett wrote:

6 Sep 2005, at 13:18, Antony Dovgal wrote:
>
>Not precisely true.
>>
>See this pseudo-code:
><?php
>>
>$first_server = new Memcache();
>$second_server = new Memcache();
>$third_server = new Memcache();
>$fourth_server = new Memcache();
>>
>?>
>>
>Nothing prevents you from using as much servers as you want in the
>same time.
>>
>I'm a strong believer that it's better to write couple of lines in
>PHP and have 100% flexible API then to hardcode some logics into
>the extension and have to work around it every time to get the
>desired behaviour.
>
This is what we do at the moment, but the main issue with this is
that there's no failover. In order to implement proper failover
you'd need to detect when a server has died and record that fact in
shared memory (which PHP doesn't have reliably, which is why we're
using memcached in the first place), so you don't have to attempt
to connect to a dead server every time. This is a big pain.

We don't do proper failover at present (if one of our web nodes
dies, our site is unusable), which is why we were looking to use
the mcache extension to implement it.

Russ Garrett
russ (AT) last (DOT) fm

6 Sep 2005, at 14:25, Alex Stapleton wrote:

Hi Russ ;)

Very short timeouts and machine local status tables (in memcached /
turckmmcache / eaccelerator / whatever you want ) seem to produce
pretty reliable fail over for us. Throw in some timeout's and
register_shutdown_functions()s to recheck the server periodically
and it actually starts to get pretty nice.

As long as your connect() time-out is low enough to merely make it
look like the page took slightly longer than normal to load, you
shouldn't have anything to worry about. It means you have a higher
potential for false positives but we haven't had any of those yet
with our time-out set to 500 ms.

Even if you use something which has a habit of forgetting about
keys (e.g. turck) it's not too painful as the failed connection
attempt ratio still tends to stay low enough to not be particularly
noticeable.

It *is* you

No chance on going open-source on your code then? I'll have to do
it myself Someone's got to do it sooner or later.

I was somewhat resigned to doing it myself in the end, but I
completely forgot about eaccelerator as a means of local shared memory.

I'm certainly not going back to a libmemcache-based solution in a
hurry after the amount of grief it's caused me over the various times
I've tried it.

Russ
russ (AT) last (DOT) fm

6 Sep 2005, at 16:33, Russell Garrett wrote:

6 Sep 2005, at 14:25, Alex Stapleton wrote:
>
>Hi Russ ;)
>>
>Very short timeouts and machine local status tables (in
>memcached / turckmmcache / eaccelerator / whatever you want ) seem
>to produce pretty reliable fail over for us. Throw in some
>timeout's and register_shutdown_functions()s to recheck the server
>periodically and it actually starts to get pretty nice.
>>
>As long as your connect() time-out is low enough to merely make it
>look like the page took slightly longer than normal to load, you
>shouldn't have anything to worry about. It means you have a higher
>potential for false positives but we haven't had any of those yet
>with our time-out set to 500 ms.
>>
>Even if you use something which has a habit of forgetting about
>keys (e.g. turck) it's not too painful as the failed connection
>attempt ratio still tends to stay low enough to not be
>particularly noticeable.
>
It *is* you

No chance on going open-source on your code then? I'll have to
do it myself Someone's got to do it sooner or later.

I was somewhat resigned to doing it myself in the end, but I
completely forgot about eaccelerator as a means of local shared
memory.

I'm certainly not going back to a libmemcache-based solution in a
hurry after the amount of grief it's caused me over the various
times I've tried it.

Russ
russ (AT) last (DOT) fm

course it's me :P

Currently we aren't using memcached in production but we are planning
to shift some stuff onto it soon. We use that technique to get around
having to use the (generally crap and ancient) F5 load balancers
which have been in use for eon's because someone didn't think about
the bottleneck it might cause. I see no reason why it wouldn't work
for memcached though. So no, I don't have any memcached code that I
could open source.

apr_memcached looks good. I've not used it though. I believe SWIG has
some vague PHP support these days, so that might make life a bit
lazier too. Personally I think the best solution is probably sticking
with your existing code for now and extending it with PHP as much as
you can. Unless your getting crap performance from your PHP code, in
which case I don't see anything wrong with just enhancing the PECL
module to whatever your PHP code looks slowest. It's not like a bit
of C is beyond your abilities ;)

Considering maintaining the server list turned out to be about 30-40
lines of code at most, it's really not a big deal to implement. I can
probably rip out the relevant bits and e-mail them to you for
inspiration if you want? It's probably bugged anyway, so some fresh
eyes would do it good.

Well, it shouldn't be hard to put ours together, I was just wondering if
there was an easier way (which it appears there isn't). It'll only take
a second to add proper failover support to our class, but I've got
bigger fish to fry at the moment.

We're not seeing a bottleneck on memcache at the moment (I thought we
were but I was wrong), so I'll cross that bridge when we come to it.

Russ

Alex Stapleton wrote:

Currently we aren't using memcached in production but we are planning
to shift some stuff onto it soon. We use that technique to get around
having to use the (generally crap and ancient) F5 load balancers
which have been in use for eon's because someone didn't think about
the bottleneck it might cause. I see no reason why it wouldn't work
for memcached though. So no, I don't have any memcached code that I
could open source.

apr_memcached looks good. I've not used it though. I believe SWIG has
some vague PHP support these days, so that might make life a bit
lazier too. Personally I think the best solution is probably sticking
with your existing code for now and extending it with PHP as much as
you can. Unless your getting crap performance from your PHP code, in
which case I don't see anything wrong with just enhancing the PECL
module to whatever your PHP code looks slowest. It's not like a bit of
C is beyond your abilities ;)

Considering maintaining the server list turned out to be about 30-40
lines of code at most, it's really not a big deal to implement. I can
probably rip out the relevant bits and e-mail them to you for
inspiration if you want? It's probably bugged anyway, so some fresh
eyes would do it good.