Perrin Harkins writes: > My preferred design for this is to set one cookie that lasts forever and > serves as a browser ID.
I like this. It's clean and simple. In this sense, a browser is not really a session. The only thing I don't like is garbage collection. > unique browser ID (or session ID, if you prefer to give out a new one > each time someone comes to the site) lets you track this for > unregistered users. We call this a visitor id. In the PetShop we have a cart id, but we're not too happy with the abstraction. > I don't see that as a big deal. You'd have to delete lots of other data > associated with a user too. Actually deleting a user is something I've > never seen happen anywhere. We do. Especially when we went from free to fee. :-( The big issue I have with "session data" is that it is often a BLOB which you can't query. > Well, eToys handled more than 2.5 million pages per hour, but caching > can be important for much smaller sites in some situations. I'd like numbers on "smaller" and "some". :) > Here's a situation where a small site could need caching: We cache, too. An interesting query is the "club count" on bivio.com's home page. The count of clubs is a fast query, but the count of the members is not (about 4 seconds). We compute a ratio when the server starts of the members to clubs. We then run the club count query and use the ratio to compute the member count. We restart the servers nightly, so the ratio is computed once a day. > Maybe I just have bad luck, but I always seem to end up at companies > where they give me requirements like these. It's the real world. Denormalization is necessary, but only after you test the normal case. One of the reasons I got involved in this discussion is that I saw a lot of messages about solutions and very few with numbers identifying the problem. Rob
