PHP/PECL C Memcache extension slowness?

[Brad Fitzpatrick]

Network duplex mismatch?

Is the C code doing flushes/send()s at the wrong time, not in lumps?
Nagel algorithm on?

The PHP client code should turn Nagel off, or use TCP_CORK/TCP_UNCORK
(BSD: TCP_PUSH/TCP_NOPUSH).

Record with tcpdump a single set/get.  See if it's using too many packets,
and delayed.



On Fri, 12 Mar 2004, Justin Matlock wrote:

> This is an odd one, and I was wondering if anyone else was seeing this.
>
> I just migrated my internal API for memcache that used Ryan's API to use the
> latest and greatest pecl.php.net version.  I wrote PHP Code to select the
> correct memcached server, hash the keys, etc., (basically stealing that from
> the old PHP API).
>
> And now my site is now *slow*.  Super slow.  Like... Running the site on a
> 33mhz 386 slow.  :)
>
> It takes 40 seconds to set 1000 key/value pairs, and 40 seconds to read
> them.  When I switch back to the PHP-only API, this happens almost instantly
> (less than 0.4 seconds for both set and get).
>
> The memcached server's not the problem:  it's a Dual Xeon 3ghz; with 12 GB
> RAM, and *only* running memcache (6 daemons, on different IP's)
>
> Here's the PHP CLI code I used to test my theory that there's something
> wrong with the C code:
>
> --- snip ---
>
> #!/usr/local/bin/php
> <?php
>
> $memcache = memcache_pconnect('10.20.0.10', 11211);
>
> $start = time();
> for ($x=0;$x<1000;$x++)
> {
>         $memcache->set("test_".$x,md5(microtime));
>         echo "$x\n";
> }
> $end = time()-$start;
> echo "+++ SET in $end seconds\n\n\n";
>
> $start = time();
> for ($x=0;$x<1000;$x++)
> {
>         $get = $memcache->get("test_".$x);
> }
> $end = time()-$start;
> echo "+++ GET in $end seconds\n\n\n";
>
> -- /snip ---
>
> HP 4.3.4 (cli) (built: Mar 11 2004 13:48:16)
> Copyright (c) 1997-2004 The PHP Group
> Zend Engine v1.3.0, Copyright (c) 1998-2004 Zend Technologies
>     with Turck MMCache v2.4.6, Copyright (c) 2002-2003 TurckSoft, St.
> Petersburg, by Dmitry Stogov
>     with Zend Extension Manager v1.0.1, Copyright (c) 2003, by Zend
> Technologies
>     with Zend Optimizer v2.5.1, Copyright (c) 1998-2004, by Zend
> Technologies
>
> application server:  Linux omega 2.6.4-rc2-mm1 #1 SMP Wed Mar 10 20:53:44
> EST 2004 i686 AMD Athlon(tm) XP 2400+ AuthenticAMD GNU/Linux
> Memcached server: Linux epsilon 2.6.4-rc1-mm2 #2 SMP Sun Mar 7 22:46:48 EST
> 2004 i686 Intel(R) XEON(TM) CPU 3.2GHz GenuineIntel GNU/Linux
> Web servers:  Linux alpha 2.6.3-gentoo-r2 #2 Sun Mar 7 15:30:36 EST 2004
> i686 Celeron (Coppermine) GenuineIntel GNU/Linux
>
> Memcached v1.10 w/epoll
> Libevent 0.7c
> Memcache.c (from pecl.php.net):  /* $Id: memcache.c,v 1.8 2004/03/11
> 17:41:37 fmk Exp $ */
> (but I saw the exact same behavior with cvs v1.7)
>
> Everything on the system is the latest and greatest, compliments of
> ACCEPT_KEYWORDS=~x86 on Gentoo.  I get the same results with PHP 4.3.5RC3
> and PHP 5.0RC4 (although everything *else* breaks under 5.0.. Heh).
>
> ...
>
> A tcpdump shows that it's doing exactly what it's supposed to be doing...
> Connecting at the beginning, then issuing the "set key flag
> length\r\n[data]\r\n".  No extra traffic.  DNS is also idle (which it should
> be).  It's just slow between each set/get.
>
> Am I missing something obvious here?  This should be blindingly fast -- as
> much as 2x as fast as the PHP-only API.  My sample block doesn't even have
> to create a hash to figure out what server to use...
>
> Justin
>
>