[Fwd: Re: LSARC/2008/126 memcached 1.2.5 to be included in OpenSolaris]
Roy Lyseng
Roy.Lyseng at sun.com
Tue Feb 26 06:09:40 PST 2008
Casper.Dik at Sun.COM wrote:
>>
>> Jyri Virkki wrote:
>>> Roy Lyseng wrote:
>>>>> Thanks. Does memcached issue a warning in the log if it starts
>>>>> listening on ports at risk?
>>>> No. Do you know a way to identify ports that are at risk? I guess we
>>>> would need to communicate with firewalls in order to do this.
>>> Does it listen on all interfaces by default or only locahost?
>> The default is to bind with INADDR_ANY. You can set it to listen to a
>> single specific interface with the -l option.
>
>
> Is there any reason for memcached to expect calls from remote systems?
>
> If not, then it should not answer them/listen for them.
memcached is a very specialized component, usually being used in a
Webstack setup as an offload engine for database accesses. It is also
mostly used in larger setups where we have multiple web servers. If a
single web server would suffice, then a non-distributed cache manager
would be faster than memcached.
Thus, the typical setup would be like this:
------------------------------
| web server tier (10-10000) |
------------------------------
I I I I I I
--------------------------- ---------------------------
| database tier (2-1000) | | memcached tier (2-1000) |
--------------------------- ---------------------------
Numbers in parentheses indicate number of machines.
Database tier and memcached tier are presented at same level (they do
not know about each other).
When a data object is looked up by a web server machine, it will first
ask the proper machine in the memcached tier. If found, request is
complete. If not found, database is consulted, and object is inserted
into memcached tier.
For all practical purposes, we would assume that administrators know
what they are doing and will only assign local addresses to the
memcached machines. Memcached functions *may* be co-located with other
functions (e.g. web server tier) but this is highly unusual.
Roy
>
> Casper
>
More information about the opensolaris-arc
mailing list