Replacing apache with nginx

[Dave Cheney]

Have you considered other options, both of which have no single point  
of failure.

1. Cookie sessions, as implemented by Rails 2.0

2. Having no sessions at all, the cookie is a token into the user  
record, which is used to construct the rest of the object graph on the  
fly, as used by ebay

Cheers

Dave

On 01/10/2008, at 10:00 PM, Gena Makhomed wrote:

> 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:
>
> ==========================================
>
> for write:
>
> 1. write session data to memcached
> 2. write session data to mysql
>
> for read:
>
> 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.
>
> -- 
> Best regards,
> Gena
>
>