Whats the best way to manage memcache servers in php? Im especially concerned about adding/removing servers, or having 1 fail.
As far as I understand, if you simply comment out addServer() of the server you want to take out, it will screw up the entire cache pool. Is that right?
Currently I'm resorting to this:
Enabled:
$memcache_obj->addServer('ip', port, true, 1, 1, 15, true);
Disabled
$memcache_obj->addServer('ip', port, true, 1, 1, -1, false);
Is this a good idea?
What about storing the memcache server list. I have several servers which all need to connect to the memcache pool. Doing any changes requires me to edit the config on all of these servers.
What about storing the server list in mysql?
Two ways (as far as I know) of doing it using php's Memcache library :
the method you used, which will enable transparent failover if memcache.allow_failover is enabled. While doing this, the keys you set when the server is disabled will need to be recreated when the server is put back into production.
change memcache.hash_strategy to consistent. This will make the hash strategy less influenced by the server pool.
Either way, disabling or removing a server from the pool will have an impact and some keys will be lost in the process.
More options are found in php's Memcached (notice the d) library (but of course that will mean changes in the code).
Take a look at your php.ini and the Memcache runtime configuration for your current setup.
As a side-note, storing the server list in mysql is a bad idea. Best way to have it hard-coded. Would be inefficient to do a database connection and query only to get a list of servers which will give you connectivity to your fast storage buffer. Caching should be a way to avoid connecting and querying the database.
Related
I have three servers for single domain
I'm using nginx as loadbalancer.
I want to share php sessions across these servers.
My application is heavily dependent on session. storing sessions in files is bad idea. i'm using memcached for this.
how exactly and efficiently should i configure memcached to read and write sessions and share between servers quickly.
or any other good alternative suggestion.
As I read your question, it looks like you installed Memcache on every server (and that's why you ask about "sharing between servers" ?).
What I would do is have a server where you ONLY have Memcached on it. Each web server would connect to your instance of Memcache. You can also have a pool of Memcache servers if needed and Memcache will take care of distributing your data and sessions correctly.
First, you may want to change the way sessions are handled in PHP (for each server) in order to read session's data in Memcache. Your php.ini file will need this:
[Session]
; Handler used to store/retrieve data.
session.save_handler = memcache[d] ; memcache or memcached
session.save_path = "127.0.0.1:11211"
See how Session Handlers work. Note that you can use memcache or memcached extension. They are not the same.
Here is the documentation for both extensions:
Memcache
Memcached
If you want more details about the right memcache to pick, I suggest you check this:
https://serverfault.com/questions/63383/memcache-vs-memcached
Note that storing sessions in Memcache can be problematic. If Memcache is stopped (for whatever reason) you will loose all data you have in it. You may want to consider storing your sessions in a database and also have them in Memcache to speedup the process.
You can build a custom Session Handler to do that and make sure it suits your needs. You can read more about The SessionHandler class.
Finally, if you are open to suggestion, I would also consider using Redis instead of Memcache as it offers more features and will enable you to reload data if shutdown correctly.
How can i manage sessions between 2 or more web servers are using to manage Load balancing ?
The points that i found are
Use database session CDbHttpSession
Use cache session CCacheHttpSession
Use Security manager CSecurityManager
As Yii project Lead Qiang said , There is only one thing you need to be careful, that is the validationKey of CSecurityManager. By default, this key is automatically/randomly generated the first time and is stored under runtime directory. In multiple server environment, you should explicitly configure this property so that all servers share the same key. This key is used widely to generate hash keys for various security-related measures.
You have a couple of options:
1) If your load balancer supports it, you can enable session persistence so that the user always is sent to the same server as the one they originally hit. The benefit of this is that it's easy to setup if you don't want to change any code. The downside is that if one of your servers goes down you lose all your sessions on that node.
2) Setup a shared memcache (not memcached) session between node1 and node2. The relevant settings being.
php.ini
session.save_handler memcache
session.save_path tcp://<ip1>, tcp://<ip2>
memcache.ini
memcache.allow_failover 1
memcache.default_port 11211
memcache.hash_strategy standard
memcache.max_failover_attempts 20
It's a little tricky to setup, but once you get it working you have full redundancy between both servers if one were to go down.
3) Setup a third node to manage sessions and configure php session.save_path to be that server's ip. The benefit of this is that sessions are now managed by a third server. The downside being you lose redundancy, if that server goes down you lose sessions.
this is the best answer that i got . But I cant Use APC !!
Is there any other methods ?
Using PHP's memcache and memcached Both of them have addServer.
So I add 2 different memcache servers running on different hardware and even on different ports.
When I "set", "add" or "increment" -- which one will be choosen with memcache and which one with memcached? If one of the servers becomes unavailable, and then become available again, what happens?
And how do I turn on redunandancy/replication of data on both?
Say I want data to be stored both to server A and server B, and when one is unavailble, and then available again it gets back to whats on other server.
I think this can be done with memcache cluster, but how PHP's client libs memcache and memcached are handling that?
To get the desired effect some work has to be done on your part. I'd recommend using Membase instead, with replication turned on and persistence turned off to achieve the same effect. But first let me explain:
In both the Memcached and Memcache clients the hash of the key determines which memcache server stores the data. So which server stores the data is really dependent on the key.
Memcached allows the option to have consistent hashing (Memcached::DISTRIBUTION_CONSISTENT or Memcached::OPT_LIBKETAMA_COMPATIBLE) so that if a memache server goes down or a server is added, not all the data is reshuffled.
Not recommended but...
To achieve the desired effect (inefficiently), use consistent hashing and:
1.) Check if a server is down. Create a Memcache(d) object with only the server in question and store and retrieve a random piece of data with it. If it works, it's up.
2.) Take your working servers and add them to your server list when creating your Memcached object.
3.) Enjoy!
PS: As servers go up and down, your cache miss rates will too.
Here's a little background, currently i have
3 web servers
one db server which also host memcache for php sessions for the 3 web servers.
I have the php configs on the 3 servers to point to the memcache server for sessions. It was working fine until alot of connections were being produced for reads etc, which then caused connection timeouts.
So I'm currently looking at clustering the memcache on each web server for sessions, my only concern is how to go about making sure that memcache on all the servers have the same information for sessions.
Someone guided me to http://github.com/trs21219/Memcached-Library because i am using codeigniter but how do i converge my php sessions onto this since memcache seems as a key-value store? Thanks in advance.
Has anyone checked out http://repcached.sourceforge.net/ and does it work?
I'm not sure you have the same expectations of memcache that its designers had.
First, however, memcache distribution works differently than you expect: there is no mechanism to replicate stored information. Each memcache instance is a simple key-value store, as you've noticed. The distribution is done by the client code which has a list of all configured memcache instances and does a hash of the key to direct it to one of the instances. It is possible for the client to store it everywhere and retrieve it locally, or for it to hash it multiple times for redundancy, but these are not straightforward exercises.
But the other issue is that memcache is designed for reasonably short-lived data that memcache is allowed to throw away at any time. This makes it really good for caching frequently accessed data that can be a little stale (say up to a few minutes old) but might be expensive to retrieve (such as almost a minute to generate from a query).
PHP sessions don't really qualify for this, in my experience. A database can easily support many thousands of PHP sessions with barely visible traffic, but you need a lot of memcache storage to support the same number: 50k per session and 5000 sessions means close to 256Mb, and then there is all the other data you want to put in there. Not enough storage and you get lots of unexplained logouts (as memcache discards session data when under memory pressure) and thus lots of annoyed users who have to keep logging in again.
We've found GREAT advantage applying MongoDB instead of MySQL for most things, including session handling. It's far faster, far smaller, far easier. We keep MySQL around for transactional needs, but everything else goes into Mongo now. We've relegated memcache to simply caching pages and other data that isn't critical if it's there or not, something like smarty does.
There is no need to use some 3rd party libraries to organize memcached "cluster".
http://ru.php.net/manual/en/memcached.addserver.php
Just use this function to add several servers into the pool and after that data will be stored and distributed over those servers. The server for storing/retrieving the data for the specific key will be selected according to consistent key distribution option.
So in this case you don't need to worry about "how to go about making sure that memcache on all the servers have the same information for sessions"
All,
I have a PHP5 web application written with Zend Framework and MVC. This application is installed on 2 servers with the same setup. Server X has php5/MySql/Apache and Server Y also have the same. We don't have a common DB server between both the servers.
My application works when accessed individually via https on Server X and Server Y. But when we turn on load balancing and have both servers up, the sessions get lost.
How can I make sure my sessions persist across servers? Should I maintain my db on a third server and write sessions to it? IF so, what's the easiest and most secure way to do it?
Thanks
memcached is a popular way to solve this problem. You just need to get it up and running (easy) and update your php.ini file to tell it to use memcached as the session storage.
In php.ini you would modify:
session.save_handler = memcache
session.save_path = ""
For the general idea: PHP Sessions in Memcached.
There are any number of tutorials on setting up the Zend session handler to work with memcached. Take your pick.
Should I maintain my db on a third
server and write sessions to it?
Yes, one way to handle it is to have a 3rd machine running the database that both webservers use for the application. I've done that for several projects in the past and its worked well. The question with that approach is... is the bottleneck at the webservers or the database. If its at the database, you wont see much improvement by throwing load balancing of the web servers into the mix. You may need to instead think of mirroring schemes for the database.
Another option is to use the sticky sessions feature on your load balancer. What this will do is keep users on certain servers. So when user 1 comes to the site, they will be directed to server X. Every subsequent request will also be directed to server X. This allows you to not worry about persisting sessions between servers, as each user will continue to be directed to the server they have their session on.
The one downside of this is that when you take a web server out of the pool, half the users with a session will be logged out. So the effectiveness of this solution depends on how often you take servers out of the pool.