Replacing apache with nginx
gmm at csdoc.com
Wed Oct 1 16:00:02 MSD 2008
On Wednesday, October 1, 2008 at 5:35:29, mike wrote:
m> if the database is down, the site is down anyway;
m> so the user's loss of a session is not the biggest deal.
database may be protected by master/slave replication -
master for write, slaves for read only - site will work
with read-only access to database and read/write sessions.
m> perhaps that is one of my reasons behind asking this -
m> if the site is using the database, you can use the same connection
m> to the database for session handling as well; and if the db is down,
m> who cares if sessions are down - the *whole site* is.
using SQL database for session storage may be not useful
for performance reasons - session data updated too often,
and this will generate too many write requests for database.
>> m> depending on the size of your site you can use
>> m> a two-phase plan involving memcached and mysql,
>> this is may be too complex and/or too slow in use.
m> not really, memcached would be faster than mysql most likely,
m> but it is not persistent. which is why you would need
m> database-backing (persistence) behind it.
"two-phase plan involving memcached and mysql" is:
1. write session data to memcached
2. write session data to mysql
1. read session data from memcached
2. if all ok - finish read operation
3. else - read session data from mysql
I am right understood your proposition?
this will slowdown sql server by many write operations.
also this is more complex access protocol for backends.
>> m> use mysql cluster,
>> may be, this is the best solution. thanks for idea!
m> this is much more complex than the memcached solution IMHO :)
Mysql Cluster has no "Single Point of Failure".
complex may be only setup of cluster, not usage.
"memcached solution" is the best choice if memcached
located on fronted server and frontend is not redundant -
there is no additional "Single Points of Failure", in this
case if frontend server is down - the whole site is down too.
More information about the nginx