• The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
Menu
  • The Four Hundred
  • Subscribe
  • Media Kit
  • Contributors
  • About Us
  • Contact
  • Client/Server Performance, Part 1: Blocking

    June 16, 2010 Michael Sansoterra

    It is no secret that read performance can generally be improved by the age-old “blocking” mechanism whereby many rows are fetched at once in preparation for a program to process them. So how is blocking done in the client/server world? Assuming that the good old IBM i will be the server, the following code samples (C#, Java, VBA, and DRDA) show an example of how to increase the amount of data that can be transferred from the server to the client.

    C# Using ADO.NET and the IBM DB2 UDB for iSeries .NET Provider

    For applications that need to buffer large amounts of data, the iDB2Connection object has properties BlockSize and LobBlockSize (both specified in KB), which can be used to control the buffer size when data is requested. The larger the allocated buffer, the more rows that can be buffered and transferred at once to the client. This is advantageous for performance because it minimizes the number of trips the client needs to make to the server.

    The BlockSize property is used for “normal” data transfers from view and table data while LobBlockSize is used to control the separate buffer storage area that is used for large object data transfers (BLOBs, CLOBs and DBCLOBs.)

    The sample connection string below shows the BlockSize property being set to 512KB.

    iDB2Connection conn = new iDB2Connection(
    "DataSource=as400;UserID=MyUser;Password=MyPwd;Naming=System;
    DefaultCollection=ADVWORKS;BlockSize=512");
    

    For the V6R1 System i Access provider, the BlockSize property defaults to zero (system determined buffer), and the LobBlockSize defaults to 512.

    There is also a DataCompression property that can be used to increase transfer speeds. This property is set to True by default.

    The IBM-supplied ADO.NET provider does not offer an option to block a specific number of rows during a fetch.

    Java Using JDBC and the IBM Toolbox for Java (JTOpen) JDBC Driver

    The IBM Toolbox for Java JDBC Driver has many properties related to performance. A few of them relevant to this discussion are listed in Table 1 below (from IBM):

    Performance
    Property

    Description

    Choices

    Default

    “block criteria“

    Specifies the criteria for
    retrieving data from the server in blocks of records. Specifying a non-zero value
    for this property will reduce the frequency of communication to the server,
    and therefore increase performance.

    Ensure that record blocking is off
    if the cursor is going to be used for subsequent UPDATEs,
    or else the row that is updated will not necessarily be
    the current row.

    “0“ (no record
    blocking)
    “1“ (block if FOR
    FETCH ONLY is specified)
    “2“ (block unless
    FOR UPDATE is specified)

    “2“

    “block size“

    Specifies the block size (in
    kilobytes) to retrieve from the server and cache on the client. This property
    has no effect unless the
    “block criteria“ property is non-zero. Larger block sizes reduce the
    frequency of communication to the server, and therefore may increase
    performance.

    “0“
    “8“
    “16“
    “32“
    “64“
    “128“
    “256“
    “512“

    “32“

    “data compression“

    Specifies whether result set data
    is compressed. If this property is set to
    “true“, then result set data is compressed. If this property is
    set to
    “false“, then result set data is not compressed. Data compression
    may improve performance when retrieving large result sets.

    “true“
    “false“

    “true“

    “lob threshold“

    Specifies the maximum LOB (large
    object) size (in bytes) that can be retrieved as part of a result set. LOBs that are larger than this threshold will be
    retrieved in pieces using extra communication to the server. Larger LOB
    thresholds will reduce the frequency of communication to the server, but will
    download more LOB data, even if it is not used. Smaller LOB thresholds may
    increase frequency of communication to the server, but will only download LOB
    data as it is needed.

    “0“ – “16777216“

    “32768“

     

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Tags:

    Sponsored by
    WorksRight Software

    Do you need area code information?
    Do you need ZIP Code information?
    Do you need ZIP+4 information?
    Do you need city name information?
    Do you need county information?
    Do you need a nearest dealer locator system?

    We can HELP! We have affordable AS/400 software and data to do all of the above. Whether you need a simple city name retrieval system or a sophisticated CASS postal coding system, we have it for you!

    The ZIP/CITY system is based on 5-digit ZIP Codes. You can retrieve city names, state names, county names, area codes, time zones, latitude, longitude, and more just by knowing the ZIP Code. We supply information on all the latest area code changes. A nearest dealer locator function is also included. ZIP/CITY includes software, data, monthly updates, and unlimited support. The cost is $495 per year.

    PER/ZIP4 is a sophisticated CASS certified postal coding system for assigning ZIP Codes, ZIP+4, carrier route, and delivery point codes. PER/ZIP4 also provides county names and FIPS codes. PER/ZIP4 can be used interactively, in batch, and with callable programs. PER/ZIP4 includes software, data, monthly updates, and unlimited support. The cost is $3,900 for the first year, and $1,950 for renewal.

    Just call us and we’ll arrange for 30 days FREE use of either ZIP/CITY or PER/ZIP4.

    WorksRight Software, Inc.
    Phone: 601-856-8337
    Fax: 601-856-9432
    Email: software@worksright.com
    Website: www.worksright.com

    Share this:

    • Reddit
    • Facebook
    • LinkedIn
    • Twitter
    • Email

    Shield Unveils New DR Solution for i/OS The AS/400 at 22: Yesterday and Forever

    Leave a Reply Cancel reply

Volume 10, Number 19 -- June 16, 2010
None

Table of Contents

  • Client/Server Performance, Part 1: Blocking
  • SQL Performance: IN vs. EXISTS
  • How Do I Tell These Partitions Apart?

Content archive

  • The Four Hundred
  • Four Hundred Stuff
  • Four Hundred Guru

Recent Posts

  • POWERUp 2025 –Your Source For IBM i 7.6 Information
  • Maxava Consulting Services Does More Than HA/DR Project Management – A Lot More
  • Guru: Creating An SQL Stored Procedure That Returns A Result Set
  • As I See It: At Any Cost
  • IBM i PTF Guide, Volume 27, Number 19
  • IBM Unveils Manzan, A New Open Source Event Monitor For IBM i
  • Say Goodbye To Downtime: Update Your Database Without Taking Your Business Offline
  • i-Rays Brings Observability To IBM i Performance Problems
  • Another Non-TR “Technology Refresh” Happens With IBM i TR6
  • IBM i PTF Guide, Volume 27, Number 18

Subscribe

To get news from IT Jungle sent to your inbox every week, subscribe to our newsletter.

Pages

  • About Us
  • Contact
  • Contributors
  • Four Hundred Monitor
  • IBM i PTF Guide
  • Media Kit
  • Subscribe

Search

Copyright © 2025 IT Jungle