Devart Forums

After running a load test of a WCF service that uses EF 4.1 & the devArt EF/Oracle driver, I found excessively high CPU.

I then ran the service through the dotTrace profiler, and used the mode to determine actual CPU cycle usage (not just wall clock time, actual CPU consumption per method call that does not include waiting on IO) -- what I found was that 39% of the CPU time was burned in OCIStmtFetch, called under the covers from the devArt layer. (22% was burned in "native method execution" that the profiler couldn't track, but may be the native OCI layer)

I noticed in the OCI Oracle documentation that OCIStmtFetch is actually listed as deprecated, and they recommend using OCIStmtFetch2. Not sure this is anything related. http://download.oracle.com/docs/cd/B283 ... msc001.htm

Just wanted to run this up the flagpole to the experts, because I was surprised at the CPU not being burned in the MS EF layer itself. (We're using pregenerated views, so again, negligible CPU time was used in statement generation.) -- would assume, since is the same layer used by the ADO.NET (non-EF) dotConnect stuff, it may also have an impact.

I can provide a screen shot/export of my profiler results if interested.

Could you please specify the problem?

The situation when application spends a bigger part of time on the interoperation with the database is a usual case.

There is no essential performance difference in usage of OCIStmtFetch and OCIStmtFetch2. We call OCIStmtFetch for compatibility with very old versions of Oracle client (e.g., Oracle 8). Generally, our provider uses a common implementation that allows dotConnect for Oracle to work on any version of OCI.