I am nothing but the bearer of bad news - This issue is weird

OK - So this project just sends me from one problem to another. This one blows me away. I am hoping someone on this forum understands the ASO kernel enough to explain how it is possible for infrastruture to actually alter the kernel's retrieve times. I believed - and apparantly falsely - that once the request was made of the essbase server, I can certainly affect the speed with which the request arrives, and the speed with which the data is returned, but I did not relize you could alter the speed at which the kernel operates.

I have a report - retrieves about 200,000 cells. I did the following tests. Tests 1 and 2 the users sign onto a URL that runs through a load balancer. based on a port rule, the load balancer/VIP software send it to my APS server, as Hyperion at this level cannot truly be clustered. The APS server sends the user to one of four clustered Essbase Servers. The cube is partitioned. Essbase is on separate servers by itself. APS is on a server with EAS, HSS, Websphere, and OBIEE - server and presentation layers. (I know I know). I do not believe OBIEE is operational yet. I think that is all the details. Times are in seconds.

Test 1 – SV
http://obi.jcpenney.com:13080/aps/SmartView
116 - Spreadsheet Extractor Time
262 - User Experienced Time (From start-click to data returned)
21 sec for RCP to start fetching data

Test 2 – SV
http://obi.jcpenney.com:13080/aps/SmartView
115 - Spreadsheet Extractor Time
210 - User Experienced Time
15 sec for RCP to start

In tests 3 and 4 - I skip the load balancer/VIP and go straight to the APS server. Look how much the Spreadsheet extractor times drop - although total user experience still has serious overhead.

Test 3 – SV
http://lena099.jcpenney.com:13080/aps/SmartView
32 - Spreadsheet Extractor Time
127 - User Experienced Time
23 sec for RCP to start

Test 4 – SV
http://lena099.jcpenney.com:13080/aps/SmartView
32 - Spreadsheet Extractor Time
126 - User Experienced Time
11 sec for RCP to start

as an old-timer - I could not resist - I installed good old classic add-in to see what times were on it for tests 5 and 6:

Test 5 – CLSSIC
Direct Connect to Lena 100
37 - Spreadsheet Extractor Time
50 - User Experienced Time
15 sec for RCP to start

Test 6 – CLSSIC
Direct Connect to Lena 100
38 - Spreadsheet Extractor Time
50 - User Experienced Time
18 sec for RCP to start

So my questions:
1. What in the world is causing the extractor itself to slow down to 4x as long when the request goes through VIP/load balancer? I did not believe once the request was to Essbase anything could make it run slow, but logic tells me the request must be made in pieces... I just do not know?
2. If you have tested Smartview vs Classic - we know SV carries overhead - but what is reasonable or expected difference between it and classic? I am thinking a few seconds only. I am thinking I have serious infrastructure or configuration issues.