I'm really not understanding the problem. You have two WFE servers
running WSS and a separate SQL server. Lot's of RAM, disk space and
processing power. And, according to the post, it is running one (1) WSS
site.

What symptoms are you experiencing that would indicate there is a
bottleneck?

Placing everything on the same machine would be going the wrong
direction. Bottlenecks are relieved by increasing the amount of
resources available to the farm, not decreasing them.

What exactly we are looking is there is a large/medium server  WSS
deployment on production  server. The sites and its subsites include
70-80 subsites. The users who are accessing these sites are facing
problem of performance. The site  is very slow. Any webpart
performance, webpart page access is dead slow. some times "page can
not be displaied" occurs. There are almost 1000 users accessing sites
through internet and intranet.

Now I need to check which web application/web part is making
problems. For that I need to check the permission settings, IIS logs
Windows Performance tuning on hiting perticular page etc,

My problem is my client is ready to provide one system administrator
access which is completly indepentent system.(may be member
server).They are not ready to give any permissions on production
server to verify/check.I was told that they give a backup of WSS
site. and I need to check the performace issues in this system. This
means that I need to deploy everthing in one system(new) to verify.

Is this way, can we find out which application/webpart/webpart page/
gives problem for slow performance. Can we find the root cause of the
peformance of the site? I have a doubt because in production,
database, index, job, web servers are maintained seperatly. How can I
check all in one server evnvironment?

ok, i can certainly help you with this one - you need to dig into the symptoms
before you try to treat the disease tho :)

i have a similar topology with 270 team sites and 20+ areas on the portal -
never had issues like that. of course i dont let users use front page however.

your performance problems need to be analyzed with 2 tools:

1. WMI performance monitoring
2. network  monitor

to me it sounds like a misconfigured NLB based on what you told us, page
timeouts on a LAN are indicitave of a mis-configured network. it could also be
anything else, it just depends on which part of the documentation was skipped!

The symptoms need to be explored on the production  machines,
not in a lab environment  where they may disappear completely.

Testing performance on web parts should be done in lab environment before
deployment, but your issues are probably with the production deployment.
If the client does not want to do performance monitoring and network  monitoring
in production, then they need to provide a completely duplicate environment for
your testing so you can locate the problems. Even then, the symptoms may
disappear because the test bed may be installed correctly and production
certainly seems not to have been.

I don't quite understand their reluctance to monitor production. That should be
done routinely.
If you don't know how it performs when it is working, how do you recognize the
problems when it is not.

The best you’ll be able to do is make some approximations on your single, offline system. You can’t stress test your production  environment because they won’t let you there. But even in a single server  environment, you should be able to test the different permutations of your deployment relative to your web parts and isolate which one is the offending part.

I'm prepaing the parameters to test the root cause of the problem. Windows Server tunning parameters, Sharepoint Service tunning parameters, IIS tunning, Active directory tunning, Exchange Server tunning, database tunning.

I have to have some some tool to run and get all the report routinely. right? Do you think any other tools(other than mentioned bellow) also required to find out the problem?

I would further suggest building a mirror offline and then
adding/removing customized web parts on web site  pages using the
Application Center Tool in VS.NET to see which webparts are the
offending parts. If it turns out that none are offending, then it
stands to reason that it could be an NLB issue.

You may want to check out HTTP Compression:
www.bluedoglimited.com/.../ViewPost.aspx?ID=63