On Wednesday 22 May 2002 18:44, Dave Watkins wrote: > At 16:02 22/05/2002 +0800, Patrick Hsieh wrote: > >Hello list, > > > >I am expecting to have 30,000 http clients visting my website at the > >same time. To meet the HA requirement, we use dual firewall, dual > >Layer-4 switch and multiple web servers in the backend. My problem is, > >if we use the user-tracking system with apache, php and mysql, it will > >surely brings a huge amount of database traffic. How can I balance mysql > >load among multiple mysql server yet assure the data consistency among > >them? My idea is: > >
Actually you don't need to do clustering at all, at least not for the systems doing the actual id tracking. Use Apache's mod_unique (which will generate unique ids even across a cluster of web servers with no need for them the communicate) and then each web server can have its own user tracking database, there will be no danger of id collisions. If you need to do actual session management where you would have any of the pool of servers needing to recover per-session data, then you're stuck back where you were before, though at least you have globally unique ids now. One way to deal with that issue is to provide some form of session affinity, so once a given user session hits one particular apache, it always gets directed there. Layer 4 switching may allow you to do that. Another idea to throw into the mix is reverse proxying. Most likely you have a mix of dynamic and static content, and the static stuff really could care less where it gets served from, so set up your cluster so that each system has a stripped Apache running on port 80 which can serve static content and reverse proxy dynamic content handling off to a 2nd instance. Then you can write your proxy rewrite rules such that they take into account the user's session state, and you end up with effectively session affinity at the dynamic server, which is really the only place it would matter. Then you have no need for clustering at all, you can just replicate for reliability purposes and munge your data together from each server when you need to do reports. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]