If _I_ were doing the reporting, I'd want my Requests and Sessions on SQL like you say. However, all our corporate side is still VFP Fat Clients so they're more used to working with DBF's. Not that it'd be a big deal to get the few reports we do against our RequestLogs and such ported to SQL.

It's just I don't know if, given the fact I'm already moving the data off the local server, there's any real reason to add SQL into the mix right now. However, if there is, I'd rather tackle it now while I'm making the move. Hope that makes sense.

Thanks for your reply. Glad to know someone's out there already doing this. We are just under 4 million pageviews a month. Do you mind if I ask whether you are doing pages or all in EXE? I don't think I have to ask if you're doing COM or not. With that traffic you are most certainly doing COM. Are you running managed module or ISAPI DLL?

All our code is compiled in the Server EXE running in COM mode with 8 apps running. Our meat and potato hits average 0.05, our cart hits average 0.14, and our search is the real hog at about 0.90. It is very rare that we have a hit about 1 second at the server.

However, we like to be proactive about improving performance. Again, thanks for your reply.

Any ideas?

The biggest benefit to moving your wwession table to SQL is so that SSL persistence doesn't matter. You can fail out a web server and the end user's experience is seamless. Another web server picks up their request and knows their authentication info.

I like having a single wwRequestLog on the SQL server because I can analyze slow request, traffic history, etc. easily.

(I run a web farm with that serves 8 million+ pageviews a month.)