How about using libevent for non-blocking io instead of select()? libevent
is more effective than select().
From my test maxium size of single udp datagram can transfer successfully is
about 20K(not 64k) for local network.
Item which value size is bigger than 20k will split into several datagrams,
pecl/memcache extension has to
re-assemble them. Situation becomes even worse when some of split datagrams
lost during transmittion.
Regards,
Que Hongyu
On 5/31/07, Mikael Johansson <[EMAIL PROTECTED]> wrote:
Hi,
I've had some questions about the future of pecl/memcache, so I thought
I might as well make some sort of announcement. The new NON_BLOCKING_IO
branch represents the next major milestone and contains some rather big
infrastructure changes; as such it should not be considered production
ready (although it runs the unit-tests without fail.)
Help with testing and performance tuning/benchmarking would be much
appreciated, especially in larger setups while using UDP. New features
include:
* Non-blocking io where requests are queued onto servers and processed
in a select() loop; enables increased throughput since request
construction (serialize, compress, ..) and request parsing (deserialize,
decompress, ..) is now done in parallel with network send/recv. One
consequence is that performance should now increase as you add more
servers to the pool (before you might have seen a slight decrease.)
* Request pipelining, requests are processed as they are built and as
responses are received, senders don't wait for readers and vice versa.
* UDP support, currently only get requests use it per default but it
will be trivial to support UDP for other type of requests in the future.
* Multi-key (and pipelined) set/delete/increment/decrement (about 10x
the performance of single-key requests when doing 50-keys per request)
* Consistent hashing using crc32("host:port"), as opposed to using md5
or sha1, motivation being that crc32 is readily available and fast. Has
any standard been reached on this issue?
