We further segmented our network so that all the CF Variables traffic is on its own segment. CFVars, in a high traffic site, becomes the bottleneck quite quickly. It does an update on almost every request to your multitude of web servers. By segmenting that traffic, and dedicating a beefy machine to that purpose, your other backend traffic will be able to move around a lot better. In terms of analysis, I can't give you actual numbers, but I can tell you that this approach made it possible to keep our site responsive with 40 front end CF servers. there is absolutely no way we could have done it otherwise. Also, this approach is pretty much a security requirement. hope this helps, jeff sherwood CIO - BIGWORDS, Inc. At 06:40 PM 7/26/2000 -0600, Jim McAtee wrote: >Great post. One thing to add, and one question: > > >7. Get web log data off the servers nightly. Why store this junk on your > >web server? Archive it nightly to free space. Also, tune your web >server > >to only log the stats you ABSOLUTELY need. Otherwise you're wasting > >valuable resources on logging junk. Remove this nightly to a workstation > >with a ton of drive space so it can analyze it off-line. It sounds >simple > >and obvious, but you'll be surprised how many people don't do this. > >If you're running a log analyzer, make sure you dedicate a separate server >to just this task alone. Chewing on enormous web logs and spitting out >reports can consume a fair amount of CPU. Given a sufficient amount of >disk space, this would be a good place to archive the individual site >logs. Don't forget to ZIP them, they'll easily compress in size by a >factor of 10 to 20. > > > >9. Network Architecture. Put two NICs in every web server. The first >NIC > >goes to a high-performance (not a random brand label) 100Mb switch (a > >switch, NOT a hub) which then connects to the load balancer and then out >the > >router and any firewall tools you have. This is your outside connection. > >The second NIC goes to a SEPARATE switch (NOT the one just mentioned) to > >which your two SQL servers (in a cluster) are connected. This is your >"back > >end" network. These should be 100Mbps switched so CF can talk to SQL as > >fast as is possible. By segmenting these two connections, you get the >best > >performance. Your CF connection can get to SQL as fast as possible >through > >one means, while IIS is taking the results and getting them to the user >as > >fast as possible. Diversifying the channels maximizes the throughput and > >keeps the channels clean. > >Has anyone done much analysis on this approach? That is, how much >performance is actually gained? Say you're using 10 full T1's of outgoing >bandwidth, this ads up to just 15Mbs of that 100Mbs pipe - and if the >ethernet connection is run full duplex, that's 100Mbs in each direction. >Keep in mind that most of the internet traffic is outgoing, and most SQL >traffic will be in pulling data into the web server. I would think you'd >need unbelievable amounts of net traffic before you saw much improvement >by moving that traffic off of this link. > >Jim > > >-----Original Message----- >From: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] <[EMAIL PROTECTED]> >Date: Wednesday, July 26, 2000 5:42 PM >Subject: High-Powered Scaling - Was "Milking Every Last Drop..." > > > > > > > >Here are my suggestions > >------------------------------------------------------------------------------ >Archives: http://www.mail-archive.com/[email protected]/ >To Unsubscribe visit >http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or >send a message to [EMAIL PROTECTED] with 'unsubscribe' in >the body. !j! The mark of mediocrity is searching for the precedent. !jeff! sherwood Director of BIGWORDS.com Web Site Design / JEDI BIGWORDS.com worker#2 .r.e.c.o.v.e.r.e.d.n.e.t.s.c.a.p.e.u.s.e.r. . . . 415.543.1400.x300 ------------------------------------------------------------------------------ Archives: http://www.mail-archive.com/[email protected]/ To Unsubscribe visit http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk or send a message to [EMAIL PROTECTED] with 'unsubscribe' in the body.
