Sizing. Poor Hardware Allocation.

Problem:

Most systems we see are massively oversized, at least by some parameters or in some tiers. And even if you see some hardware utilization, it is coming not from production usage, but from OS updates, AV, logs collection by third-party tools, etc.

Some systems are fine, they have a noticeable load, at least during rush hours.

Shockingly there are critically undersized systems, to which admin teams are not paying attention, while they are constantly running out of memory or running 100% CPU for hours.

Even worse, sometimes we propose additional nodes to enhance stability or performance in specific tiers and customers resist due to budget constraints, despite their other tiers have substantial unused resources.

Solution:

Virtualization should ideally address these issues, enabling easy resources adjustments. However, this is not the reality we observe.

One reason for this is that many enterprise monitoring systems lack user-friendly interfaces, hence people don’t use them.

Convenient interfaces are an industry-wide challenge. Large companies often prioritize cool look over functionality and ease of use.

At BiWhy, we strive to present all relevant information on a single screen with minimal clicks, among other reasons because we use our tool daily 😊

With BiWhy you can analyze load from multiple servers on one screen.

OS as a whole: CPU, Memory, Network, Disk… or drill down to particular processes, their parameters, command lines, charts, table, comparisons, summary.

JDBC Fetch Size

Impact on Data Transfer Performance

Problems:

Data transfer takes considerable time, for example, due to frontend and backend are located in different data centers.

Solution:

High network bandwidth is not the only factor influencing fast data transfer. How communicating programs send information is also crucial.

If data is sent in small chunks, all network layer optimization techniques apply to each chunk, and time is spent waiting for each chunk’s data transfer to complete.

The rough time taken can be summarized as follows:

Worst case (small chunks): Round-trip time (approximation of one chunk's data transfer) * number of chunks

Best case (one big chunk): (Data to transfer) / (network bandwidth)

In the case of JDBC, chunks can be regulated by the Array Fetch Size parameter.

Note that different JDBC driver implementations might treat this parameter differently. Additionally, some engineers might be hesitant to use large numbers.

Fortunately, it is easy to test with BiWhy (it took only a couple of hours to add this functionality).

Please see screenshots with the results below:

• The default BOBJ limit of 1k rows is three times as bad as the optimal parameter!

• SAP Note: 1464707 - How To Increase The Array Fetch Size Above The Maximum

• A frequently set value of 100 rows takes 9 minutes and 10 seconds instead of 20 seconds, which is about 30 times worse than the optimal setting!

• We did not even test the frequently set, if not default, value of 10 rows for apparent reasons.

For our test, optimal range is:

• 0 – value is not set, JDBC decides

• >10k rows

From a performance perspective, it is unclear why one would set the Fetch Size to low numbers unless it is for a real-time service or there is requirement to abort after fetching a certain limit  (in this case, the suggested minimum fetch size would be limit + 1 rows).

PS: We once encountered a performance problem with a third-party ETL tool (not SAP). Despite being a large company by market cap and boasting of leveraging AI on their website, network traces showed that data was transferred in very small chunks (~10 rows), and array fetch size configuration was NOT available!

Hosts Monitoring

Monitor multiple hosts, not necessary BOBJ or even other SAP application, just any hosts where you have SAPOSCOL

Problems:

Monitor and analyze processes on multiple hosts in real time or in history on one screen

Solution:

Install SAPOSCOL, SAP utility with installation as simple as one click plus password set, on all hosts you want to monitor.

Provide host names and passwords to BiWhy and that is it.

Monitor, analyze: filter, tables, charts, summary, save/reopen results to local db file, send it for analysis.

Available metrics: process, CPU system/user/percentage, memory, command line, up time… 19 metrics overall, see screenshot for details.