On Sun, 2003-06-08 at 03:21, Roman Rokytskyy wrote:

> Hi,
>
> > Thanks for the code. I did some test setting the buffer the same
> > size as the segment size in the db.
> >
> > I can't seem to see a performance difference between doing what you
> > suggested or simply using
> >
> > sos.write(result_set.getBytes(1));
> >
> > The average time from the above was like 1 milliseconds faster than
> > the code you provide?
> > ...
> >
> > When the buffer was larger, 32767 the segment size of blobs in the
> > db, it seems performance degraded. I did not test out any other
> > combinations between 2048-32767.
>
> Blobs are fetched from the database by blocks, not segments.

Then I guess I am confused as to the segment size of blobs in the db?

> This is
> very interesting thing, because the actual API call is
> isc_get_segment. However, you specify size you want to get from
> database (max. is Short.MAX_VALUE - 2).

Ok, so that value can be greater or smaller than the "storage" segment
size on disk. What the value specifies.

I have used isc_get_segment with a C++ C API wrapper I wrote. I wanted
to learn C++ and learn about the API.

I hope to one day be able to contribute on the Java side. I would like
to in the next month or two look into making a J2ME version of the
driver. Although I am not sure I am ready for that. I need to look at
the code behind Jaybird and get an understanding of how it talks to the
db. Which I assume is not directly via the API?

> Size of the buffer is
> controlled by connection parameter "blob_buffer_size" (probably
> undocumented one), and by default is 1024 * 16.

Ok

> So, using any buffer of size less than "blob_buffer_size" in your code
> makes a little sense, since it is already buffered in driver. Bigger
> buffers cause additional fetch. So, in general, let the driver decide
> how to fetch blobs from database.

Good to know. OT Any rules of thumb to use when working at the API level
not using JayBird. I mean when using Java I can let the driver deal with
that, but what about with my C++ wrapper.

Should I use a default buffer size? Or base it on the value of the on
disk segment size? Or is there a formula to determine the preferred
buffer size based on the on disk segment size?

Or is it a trial and error thing based on the size of what is being
extracted?

> There is another thing that influences performance, socket input and
> output buffer sizes. These are set by default to the OS settings, but
> in some Linux-es (probably related to kernel version), they are
> "incorrect" (performance is very low). They are controlled by
> connection parameter "isc_dpb_socket_buffer_size". On Windows optimal
> value is 8k, seems that on Linux 8k and 16k are ok. Higher values
> decrease the performance.

That is good to know. I already see good performance with Linux to
Linux, and even Windows to Linux communication. I will play around with
that as well and see what I get. I will most likely stick with your
suggestion of 8k or 16k on Linux, and 8k on Windows.

Thanks for the info. It's greatly appreciated.

--
Sincerely,
William L. Thomson Jr.
Support Group
Obsidian-Studios, Inc.
3548 Jamestown Ln.
Jacksonville, FL 32223
Phone/Fax 904.260.2445
http://www.obsidian-studios.com