| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
cache constructors/destructors were never used, which just ended up
being wasted branches. Since there's no constructor/destructor for cache
objects, we can use the memory itself for the freelist.
This removes a doubling realloc for the freelist of cache objects and
simplifies the code a bunch.
|
| |
|
|
|
|
|
|
|
|
|
| |
allows specifying a megabyte limit for either response objects or read
buffers. this is split among all of the worker threads.
useful if connection limit is extremely high and you want to
aggressively close connections if something
happens and all connections become active at the same time.
missing runtime tuning.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This change refactors most of memcached's networking frontend code. The
goals with this change:
- Decouple buffer memory from client connections where plausible,
reducing memory usage for currently inactive TCP sessions.
- Allow easy response stacking for all protocols. Previously every
binary command generates a syscall during response. This is no longer
true when multiple commands are read off the wire at once. The new meta
protocol and most text protocol commands are similar.
- Reduce code complexity for network handling. Remove automatic buffer
adjustments, error checking, and so on.
This is accomplished by removing the iovec, msg, and "write buffer"
structures from connection objects. A `mc_resp` object is now used to
represent an individual response. These objects contain small iovec's
and enough detail to be late-combined on transmit. As a side effect,
UDP mode now works with extstore :)
Adding to the iovec always had a remote chance of memory failure, so
every call had to be checked for an error. Now once a response object
is allocated, most manipulations can happen without any checking. This
is both a boost to code robustness and performance for some hot paths.
This patch is the first in a series, focusing on the client response.
|
| |
|
|
| |
@hujiecs reported on github but repository was lost.
|
| |
|
|
| |
don't normally exercise the UMEM code :( sorry!
|
| |
|
|
|
| |
suffix cache was using a generic cache system, which uses a mutex lock. the
pools are per-thread however.
|
| |
|
|
| |
reported by javierhonduco on github
|
| | |
|
| | |
|
|
|
The suffix pool could be thread-local and use the generic cache
|
