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)
b) Caching
Caching 1 1
CacheSize 16384 16384
FileSize 1048576 1048576
TimeToLive 31 31
StaticTemplates 1 0
CacheInvalidateHour
CacheInvalidateMinute
Staticflows 1
ProductionMode 1 0
StaticBor 1 0
c) Timeout Parameters
TimeoutPercentage 75 75
d) Debugging Parameters
~rfcDebuggingOn 0 0
~rfcTraceOn 0 0
AdminEnabled 0 0
localTraceLevel 0 0
SAPDebuggerDelay
e) Miscellaneous
MinRespSize 32768 32768
MaxRespSize 2097152 2097152
MaxServiceContextSize 20480 20480
~http_compress_level 7 7
~http_use_compression 1 1
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).
