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