RE: back-sql improvements (was: Slapd frontend performance issues )

["Arredondo, Tomas" <tArredondo@unispherenetworks.com>]

Hi Dmitry,

Comments inline.

Regards,
Tomas

-----Original Message-----
From: Dmitry Kovalev [mailto:mitya@seismic.geol.msu.ru]
Sent: Tuesday, April 10, 2001 6:52 AM
To: Arredondo, Tomas
Cc: openldap-devel@openldap.org
Subject: back-sql improvements (was: Slapd frontend performance issues)


Hello Tomas!

As this thread eventually spinned down to back-sql, I thought it would be
reasonable to rename it...
I think two separate threads are appropriate - one about back-sql - specific
issues, and another - about slapd frontend profiling.

Also, if you have no objections - let us transfer posts that have more than
one
recipient to the list.
As I understand, it is what Kurt suggested - use -devel list for
development.
Kurt, if you think that too much back-sql specifics is bad for this list - I
could arrange a temporal list for this, and post only results to
openldap-devel.


"Arredondo, Tomas" wrote:

> I think that in an optimal environment it should exceed 100 reads/second.

did you test the "packaged" back-sql, or you made some optimizations? what
was
the data you tested on?

[TA] The OCI data access library has been tested to go about 100 reads/sec
with a different application.  I have not integrated this with back-sql or
OpenLDAP and so I could
not tell you how fast an OCI version of back-sql could be.  I would think it
should be pretty
close unless there is a massive amount of processing going on in back-sql.
>
> There are two pieces to the code that I could help with.  One is a set of
> routines that can make db calls to read and write data using connections.
>
> The other is a set of connection related classes that can manage
connection
> handles from
>
> OCI and other formats such as ODBC concurrently.
>
> These connection classes are things we can call 'dbo', 'sets' and
> 'connections'.

[description skipped]

as I undestand, it could be used
1) to use direct APIs (lightweight wrapper)
2) to "aggregate" data from different RDBMSes in single slapd

[TA] Right, the 'dbo', 'sets' and 'connections' are a potential way to
abstract different connections
to different RDBMSes in a single slapd.  These are currently used with OCI
but I tested them
previously with ODBC (a couple of years ago).  OCI and ODBC are from a
connection point of
view very similar so a lightweight wrapper could use this abstraction to so
that depending on the
connection type the underlying direct API would change but to the caller it
would be transparent
except for the connection type used to create the 'key' (OCI, ODBC,...).

Am I right? It is very interesting, anyway - as soon as we manage to
summarize
what each of the contributers can offer, we can develop a little "plan" of
incorporating new code in appropriate order...

[TA] Sounds great.   I'm flexible, any plan is better than none! :-)

WBW, Dmitry