Re: UTL_RAW and slowness

Raj,

When I was writing the PL/SQL implementation of Blowfish, I also wrote a version as a Java Stored Procedure so I could compare the performance of the two implementations. For CPU intensive work (like encryption), the Java Stored Procedure performed orders of magnitude better than the PL/SQL version. I was using 8.1.7 at the time.

I am wondering why you need to flush the TCP connection after 128 bytes?

Have you profiled your code using DBMS_PROFILER to see where the time it being spent?

Cheers,
Craig.

At 04:09 PM 23/10/2003 -0800, you wrote:

>Raj,
>
>I'll try to be tactful here, but that isn't encryption. It only looks like
>encryption, and is in fact very easy to break.
>
>Check out the article at
>http://www.cybcon.com/~jkstill/util/encryption/encryption.html
>
>There are PL/SQL implementations of RC4 and Blowfish there. RC4 is a
>stream cipher
>and Blowfish is a block cipher. Either would suit your purpose.
>
>Blowfish is there courtesy of Craig Munday.
>
>RC4 is there courtesy of a leak at RSA, but it's in the public domain now,
>so that
>doesn't matter anymore.
>
>Also check Pete Finnigans site: http://www.petefinnigan.com/
>
>HTH
>
>Jared
>
>
>
>
>"Jamadagni, Rajendra" <Rajendra.Jamadagni_at_espn.com>
>Sent by: ml-errors_at_fatcity.com
>
> 10/23/2003 02:54 PM
> Please respond to ORACLE-L
>
> To: Multiple recipients of list ORACLE-L
> <ORACLE-L_at_fatcity.com>
> cc:
> Subject: UTL_RAW and slowness
>
>
>Hi all,
>
>I am experimenting with a block of pl/sql code (wrote myself) that uses
>utl_raw to perform xor operation. (Note to Jared and Mladan, I can't use
>Perl on production boxes, so don't even go there).
>
>I take a message, encrypt 1 character send it out on a wire using utl_tcp.
>After every 128 bytes, I flush the tcp connection. While this works fine
>and within our acceptable range for smallish messages (up to 20-25K in
>size), it nearly kills itself when working with larger messages (80k+).
>
>Initially I could encrypt 128 characters (including conversion from/to
>utl_raw) in about 50ms. Bt this increase progressively. When I reach about
>98000 to 99000 range, it takes about 16 seconds to encrypt 128 characters.
>
>I have logged tar with Oracle, but does anyone know if one could do a
>block encryption (can't use standard algorithms, this is custom) like
>encrypt 128 characters at a time instead of 1 ...
>
>The skeleton code looks like this ...
>
>msglen := LENGTH (msg_text);
>nCharsSent := 0;
>p('Encrypting data...');
>FOR i IN 1 .. msglen
>LOOP
> ntcpchar := ASCII (SUBSTR (msg_text, i, 1));
> r_chr := utl_raw.cast_to_raw(CHR(ntcpchar));
> nenctcpchar := TO_NUMBER(utl_raw.bit_xor(r_chr,r_key),'xxxx');
> tcpmsglen := UTL_TCP.write_text (gv_tcp_conn, CHR(nenctcpchar), NULL);
> nCharsSent := nCharssent + 1;
> IF MOD(ncharssent,128) = 0 THEN
> p('Before Flush ...');
> UTL_TCP.FLUSH (gv_tcp_conn);
> p('Connection Flushed at ' || ncharssent);
> END IF;
> --
>END LOOP; -- FOR i IN 1 .. msglen
>
>where p is a procedure that dumps supplied text to a trace file with a
>timestamp that is up to 1 ms resolution. BTW this is a 9202 box. Also when
>it starts getting slow, using "nmon" I can see that this process is
>hogging a CUP at 99-100%. Of course this is a dev box, but my SA will not
>like this on a production box.
>
>Any ideas?
>Thanks in advance
>Raj
>--------------------------------------------------------------------------------
>
>Rajendra dot Jamadagni at nospamespn dot com
>All Views expressed in this email are strictly personal.
>QOTD: Any clod can have facts, having an opinion is an art !
>
>
>
>**************************************************************************************
>This e-mail message is confidential, intended only for the named
>recipient(s) above and may contain information that is privileged,
>attorney work product or exempt from disclosure under applicable law. If
>you have received this message in error, or are not the named
>recipient(s), please immediately notify corporate MIS at (860) 766-2000
>and delete this e-mail message from your computer, Thank you.
>**************************************************************************************5
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.net
-- 
Author: Craig Munday
  INET: cmunday_at_bigpond.net.au

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).