We had ittermittant slowness during one period. Then we discovered a dev who would at random times during the day copy 800GB-1.5TB files across the network.
Just a thought. On Thu, Jun 9, 2011 at 5:36 AM, Ziots, Edward <[email protected]> wrote: > I would recommend that fiddler HTTP proxy be added to 2 representative > workstations, going to the same website, one outside and one inside, and > look at the traffic dump to see where things might be slowing down, its > saved me a lot of work in the past, either verifying there is a web problem, > or debunking the web problem accordingly. > > > > Here is where to get the fiddler HTTP proxy, and there is a lot of nice > add-ons to the utility. > > > > www.fiddler2.com > > > > Z > > > > Edward E. Ziots > > CISSP, Network +, Security + > > Security Engineer > > Lifespan Organization > > Email:[email protected] > > Cell:401-639-3505 > > [image: CISSP_logo] > > > > *From:* Andrew S. Baker [mailto:[email protected]] > *Sent:* Thursday, June 09, 2011 6:25 AM > *To:* NT System Admin Issues > *Subject:* Re: OTish: Need some ideas on troubleshooting web browsing > problem > > > > Doesn't the fact that there is no consistency in the data from systems > placed at different points in your network *helpful* to determining where > there is a potential slowdown? > > Users complain about slow performance, and your logging shows that speeds > outside are faster than those inside. > > This would indicate that something on the inside is a bottleneck at that > time... > > It would seem to me that you have more than enough data to drill down and > find out where the issues are taking place. > > > > *ASB *(Professional Bio <http://about.me/Andrew.S.Baker/bio>) > *Harnessing the Advantages of Technology for the SMB market...** > * > * * > > > > On Thu, Jun 9, 2011 at 1:12 AM, Kurt Buff <[email protected]> wrote: > > All, > > I'm in need of a new approach to troubleshooting staff complaints > about intermittent slowness of web browsing. We have about 200 staff > members on site, the symptoms are intermittent at best, but include > some generalized slowness in page loads, and occasional complete page > misses - that is, staff report that a page fails to load at all, with > a message that the system can't find the page, but hitting refresh > will usually bring the page right up. > > My current testing methodology seems to be getting me nowhere and > causing me to lose hair in great chunks. I outline the methodology > below because someone might spot a flaw in it. > > I'm not well versed in reading packets, so haven't yet resorted to > wireshark or tcpdump, but my testing so far leads me to believe that I > won't find much that way. If your reading of the situation leads you > to believe otherwise, I'm all ears. But I'm also really interested in > hearing other things all y'all might suggest on how to go about this. > > Network physical configuration: > DS3 >> HP 2524 switch >> Sidewinder firewall >> HP 2524 switch >> > Barracuda web filter >> HP 3400cl switch >> production VLANs > > Network logical configuration: > No VLANs externally, 9 VLANs that run over the 3400cl and 18 > VLANs (the ones on the 3400cl, plus 9 for test/dev/other) that run on > the internal HP 2524. The firewall is a HA pair (active/passive) and > has a VLANed interface to the HP 2524 - it sees all of the VLANs. > > Other data: > I've got ntop running on two different points on the network - > the external HP 2524, and the HP 3400cl - no load anomalies for the > LAN or Internet connection noted. > > Testing methodology: > I have placed a FreeBSD box with a public IP address external to > the firewall, and two FreeBSD boxes internal to the firewall on > different VLANs. One of the internal FreeBSD boxes is on a VLAN that > doesn't traverse the 3400cl, and the other is placed in a VLAN that > does - both VLANs transit the Barracuda, as do all staff machines. > Each box has cURL installed (there's a version for Windows as well), > and is given an identical list of about 2100 unique (http://fqdn only > - not http://fqdn/somepath) URLs to resolve and download. I kick off > the batch files manually - and simultaneously. > The batch file is simple: > date > /root/out.txt > /usr/local/bin/curl -K /root/urls.txt >> /root/out.txt > date >> /root/out.txt > The entries are all formatted similarly, e.g.: > url = "http://www.google.com"; > -s > -w = "%{url_effective}\t%{time_total}\t%{time_namelookup}\n" > -o = /dev/null > The output looks like this: > http://www.google.com 0.093 0.066 > Downloaded data is dumped to /dev/null, but I capture the timings > for name resolution and the total transaction so that if I want I can > analyze them later. I used this method before to identify a problem > with the DNS proxy on the firewall, so thought this would be a useful > method to do the same thing. > All three boxes are using Google for name resolution: 8.8.8.8 - > so that I can eliminate variances based on possible problems with our > AD DNS infrastructure - I don't think there are any, but.... > Currently, our AD DNS points to 8.8.8.8 for its resolvers, but > was originally pointed at our ISPs DNS - that change doesn't seem to > have made a difference in staff experience. > I gathered the URLs from my syslogs, so they are real sites that > people here visit. > > The problem with the results from the methodology: > Using the same data files each time, timings across all three > boxes have varied wildly. On Friday of last week, each of the three > boxes took 40 minutes to run through the list of URLs. On Tuesday they > each took roughly three hours. Today the external box took 40 minutes > and one of the internal boxes took about 3 hours, and the other > internal machine hadn't finished by the time I left work - cURL hung > on that machine and I'm going to rebuild it, as it had been mothballed > and only revived for this test, and really needs updating. Because > there is no consistency in the data, I cannot draw any conclusions. > I'm going to try a few more runs, but definitely feel the need for a > different approach > > Any thoughts you might have will be appreciated. I'm out for the next > couple of days, so won't be able to try any suggestions until next > week, but would love to hear from folks on this. > > Thanks, > > Kurt > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ > ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ > > --- > To manage subscriptions click here: > http://lyris.sunbelt-software.com/read/my_forums/ > or send an email to [email protected] > with the body: unsubscribe ntsysadmin > ~ Finally, powerful endpoint security that ISN'T a resource hog! ~ ~ <http://www.sunbeltsoftware.com/Business/VIPRE-Enterprise/> ~ --- To manage subscriptions click here: http://lyris.sunbelt-software.com/read/my_forums/ or send an email to [email protected] with the body: unsubscribe ntsysadmin
<<image001.jpg>>
