Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations gkittelson on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

IP Chunk Size

Status
Not open for further replies.

wolf5370

Programmer
Nov 20, 2000
43
GB
Hi,

After having some performace issues with 7.2.1, we set up a network sniff to try and see what was happening.

One of the interesting things we saw was that their seems to be continual handshaking between the client and the web server while running a report.

We have the polling interval set to 10 seconds, but are getting handshakes at 8 times per second.

Also the chunk size is a maximum of 1.5K rather than more optimal 4k chunks - i.e. the header is split in to three - compounding the problem.

I have asked gold support, but they are not very forth coming (they have the sniff output and are still looking at it a month down the line).
Does anyone know if it is possible to change the chunk size to a more optimal 4K.

Note: this makes no difference if web is in Get or Put mode (i.e. all on a single header - bigger and thus more pieces, or on two headers and chopoped half as much).

I don't think this has anything to do with the performace problems, per say, though it may explain why the web servers (load balanced dual 1.4Mhz 4GB machines!) are maxing out at 300 or so active users - just too much traffic!

(I have also launched a thread to do with the client performance issue, so light on it here).

Cheers,

Wolf
 
Here are some possibilities to check out

- Check MaxClientRequestBuffer setting of your IIS
- See if your keepalive setting is checked in MSTR Web. Try disabling it. If not it will send packets to keep the connection alive to the web server. 7.2.1 Hotfix 2 and above has a way to specify the keepalive timeframe
- some SSL connections also use secret handshakes, not sure if this applies
- i don't think MicroStrategy uses chunked encoding but you can view source to see if the web pages do it
- Finally I would make sure the IIS is not setup with some sort of multicasting application.

good luck.
 
Cheers Nlim,

Don't use SSL so not applicable, but will check out the rest of your comments and post back.

Thanks,
Wolf
 
Nlim,
Could not find the MaxClientRequestBuffer setting in IIS (we are on IIS 5.0)?
Disabled keepalive setting, but this killed the project (continual 404s)
No SSL used
Chunk Encoding - Not sure how this would be done, but nothing unusual per sya on the web pages.
Make sure the IIS is not setup with some sort of multicasting application - IIS is set up with normal defaults, with the exception that we switch off anominous access.
Cheers,
Wolf
 
do you use WLBS with cisco switches? If so, see
although it's a mystery why HTML is ok while DHTML is not.

Maxclientrequest is set in the registry.

I pulled the following text from one of their benchmarks, see if it's useful...

"MicroStrategy Web uses a set of ASPs that communicate with the MicroStrategy Intelligence Server. MicroStrategy
Intelligence Server processes these requests and sends the results to the Web Server. The Microsoft Internet Information
Server (IIS) on the web server should be optimized for use with MicroStrategy Web. These guidelines can be found on
Microsoft’s MSDN1. For the purpose of this benchmark, the thread pool and queue pool were optimized.

The thread pool is the total number of threads per processor that can be used to service any ASP request. In Microsoft’s
IIS the thread pool is controlled using the ProcessorThreadMax setting. As stated by Mike Moore in his paper “Tuning
Internet Information Server Performance” (MSDN October 30th, 1997) the same way you would add extra lanes on a
congested highway, you can add ASP threads to process more requests at the same time.

The queue pool is controlled by
the RequestQueueMax setting. The queue pool is the number of ASP requests that are waiting to be processed by the
ASP threads at any given time.
Modifying these 2 parameters can improve web server response time by allowing the maximum possible number of ASP
requests to be processed concurrently. The idea is to set ProcessorThreadMax to obtain approximately 80% CPU utilization
during peak hours.


The ProcessorThreadMax setting in Windows 2000 can be modified by running the following script:
C:\inetpub\adminscripts\adsutil.vbs SET w3svc/1/ASPProcessorThreadMax N
Where N is the number of ASP threads per processor

For the purpose of this paper tests were executed while modifying these parameters to obtain maximum CPU usage on
our Web Servers without creating a bottleneck. Historical testing has shown that a CPU-utilization of approximately
85% is the ideal value as performance will degrade at higher utilization rates. The ProcessorThreadMax setting was
between 10 and 15 for these tests."
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top