You have 10 users accessing sap via an ITS server
(6.20) and it is soooo slow !!! access via sapgui is fast - any ideas what to
look for ??
We tested several options for deploying the SAPGUI :-
Tivoli packages
ITS
Citrix MF XP
Tivoli was already built and in house so all we had to
do was create a SAPGUI package and deploy it to the field (3000+ users) - pain
in the butt because we had to find out all the users workstation id's for the
users in 900+ locations. So far we have deployed 35% and our Go-live is 10/01!
ITS - We had an ITS consultant come in and review our
setup. We were able to enhance the performance to some extent (20%). But, that
was still unacceptable in comparison to the WINGUI that the users are now
accustomed to. In short, we scraped the ITS project because of the problems with
latency/performance. Our connection between our test locations and the Data
Center was 100MB. The other locations were 10MB.
ITS Tuning in relating to performance of the ITS
Server
1. HKEY_LOCAL_MACHINE\Software\SAP\ITS\2.0\<ITS
instance>\Programs\SAPjulep\StaticTemplats
To simulate the test, the parameter for Static Templates
was changed from 0 to 1
Recommendation : Development system = 0 ; Production
System = 1
2. ITS Parameters / Recommended / Ours
a) Worktreads and Sessions
MaxSessions 400 400
MaxWorkThreads 64 40 (can be reduced)
MinWorkThreads 64 40 (can be reduced)
2. Load Balancing and Multiple Agates
IncAGates 1 (Do not modify this value.)
MinAGates (Do not modify this value.)
MaxAgates (Do not modify this value.)
IncWorkThreads 1
3. Windows Environment Settings
4. SAP R/3 Parameters
rdisp/gui_auto_logout >= ~userTimeout
3. Check the following internet option settings.
Under "Advanced", make sure both HTTP 1.1 settings are on
Under "Security", "Custom Level" under the point
"micellaneous" make sure these are ENABLE:
a) access the data sources across domains
b) Launch programs and files in IFRAME
c) Migrate sub-frames across different domains
4 Verify Compression. These values were changed in the
global.srvc file
~http_use_compression 1
To increase the transmission speed and reduce the overall
network load we reduce the size of the data sent from the server to the web
browser by using compression. The values are 0 to disable compression and 1 to
enable compression.
~http_compress_level 7
The compress level can be set between 1- 9 where 1 is the
lowest compression level and 9 is the highest. The higher the value set for
~http_compress_level, the better the compression achieved.
The Level 1 achieves the lowest compression level/
fastest procession speed and Level 9 achieves the highest compression
level/slowest procession speed
5 ~navigationenabled : Enables / Disables Drag & Relate
functionality in the SAP GUI for HTML.
Using Drag & Relate in the SAP GUI for HTML requires a
callback from the R/3 System for nearly every request / response cycle. This is
an unnecessary overhead for many applications. Hence we disable Drag&Relate by
setting this parameter to 0 in the webgui.srvc file on the Agate.
Citrix proved to be just too expensive an option for
right now. The SAP 4.6d protocol proved to be quite thin, with the bandwidth
requirements tracking only slightly greater than ICA. However, on a number of
occasions over the test period, it was observed that SAP could demand a
considerable amount of bandwidth for short bursts. This traffic was primarily
outbound, targeted at port 4803. However, even with the thin nature of SAP, ICA
still provided a bandwidth advantage.
To better understand this and develop conservative
figures, a trend analysis of the data was performed. This analysis allowed for a
weighted smoothing of the statistics, lessening the impact of the burst type
activities. Based on the trend figures, the following observations where made:
SAP showed an overall Kbps trend average of 2.5 Kbps
ICA showed an overall Kbps trend average of 1.7 Kbps
Overall, ICA showed a 30% improvement in bandwidth
utilization when compared to SAP, based on the trend analysis of the data. This
margin jumps to almost 70% when averages are analyzed.
The maximum SAP burst activity exceeded the maximum ICA
burst activity by 70%.
Both SAP and ICA displayed extremely limited network
utilization. Over extended periods, ICA displayed consistently low inbound
traffic, trending towards .8
If all you have is 10 users, what's wrong with
deploying the SAPGUI?
The ITS environment was initially created with very
minimal customized configurations (2 servers Dell 2650's). Most ITS performance
parameters were accepted as default. We tested over dual T1's (1.5MB) as well as
Ethernet 10/100MB max.
For each request by the webserver, a separate request
is made to the backend - so what you get is a constant request/send, even though
each one is milliseconds adding hundreds of requests through the WGate to AGate
to R/3 you can see there just isn't much you can do to improve the speed.
To help diagnose the network or measure network
metrics, we used a program from SAP called �NIPING�. Niping is a test program
for the network interfaces (NI) layer. It provides connection and performance
test with the same mechanisms that the SAPGUI uses. To test the network, the
niping tool runs a continuous test. It generate and evaluate a network trace
simultaneously from the ITS server and the front end. We ran several niping
tests and the following results were produced.
Since the communication between the client and the Web
servers is over the HTTP protocol, SAP-ITS also makes the SAP transactions
accessible to distant locations via the Internet, enterprise networks, and
virtual private networks. These networks are typically very complex and have
many users. As the distance between the nodes and the complexity of the network
increase, application performance becomes an important issue. The performance of
a network depends mainly on two
different factors - the bandwidth (throughput) and the
latency (delay).
Bandwidth is the most commonly known factor affecting
performance of a network. Network bandwidth defines the amount of data that can
be transferred at a given time. Networks with higher bandwidth provide better
performance.
The second factor relating to performance of a network
is latency. Latency can be defined as the delay in processing data within the
network. A network with lower latency performs better than a network with high
latency.
In addition to the individual effects on bandwidth and
latency within the network, their combination can also affect the quality of
communication, hence determining the overall network performance (network
speed).
