"Christopher" wrote in message
> We implement our SQL queries in our applications using embedded SQL/C
> and the esqlc precompiler. We now have serious performance problems on
> the client side.
> Our Setup is the following (but we have similar Problems using other
> setups):
>
> Server: Win XP Pro, Ingres II, 2.6, DBMS, Net
> Client: Win XP Pro, Ingres II, 2.6, Net Client
>
> Responses to queries issued from the client are 7 times (and even
> more) slower than the same query issued on the server. The load on the
> server ist minimal: no one else than the client has access to it,
> because it's a test environment.
>
> We analysed the program execution using a profiler. It reports that
> the most time on the client is consumed by a function called GCsync()
> in OICLFNT.DLL.
>
> The tmdemo test program from the Ingres SDK shows the same effect.
How many rows are you getting back? I immediately suspect row-at-a-time
transfer over a busy network.
> We also mesured the query answer time using II_EMBED_SET (set
> II_EMBED_SET=printqry;qryfile c:\temp\output.txt) while issuing the
> same queries on client and server. As far as we can see, the time
> difference between a server and client query is negligible, but I'm
> not sure if our interpretation of the output is correct (does anybody
> knows more details about the correct interpretation of this output?)
> Example:
> Query text:
> execute query (myquery115) 1 255 5400 5599
> Query Send Time: Thu Jul 29 13:21:43 2004
> Query Response Time: Thu Jul 29 13:21:43 2004
> Response CPU Time: 500
> Qry End CPU Time: 500
This trace is generated at the client end of the query. In the case of a
query from a workstation it shows the time the query was sent to the server,
and the time the server finished sending results back, across the network.
In the case of a client running on the same machine that also hosts the
server, it shows the same information except there would be no "wire
network" delays.
> So the key questions are:
> - Is anybody out there who has similar problems?
These things crop up all the time. I don't know anyone who doesn't have
them.
> - How can these problems be solved?
In innumerable ways. You'll need to provide lots more background
information. We'd need to see the SQL (with actual criteria), the table
definitions, and a trace done when there was a problem. (I'm not clear if
you are asserting the one above was done when a problem occurred, or not.)
If the one above shows what happened when you had a slow response then I'd
say it's not an Ingres problem.
If the above was not a slow query, then looking at the BIO count before and
after running a slow query might be instructive. (Use select
dbmsinfo('_bio_cnt').)
Roy Hann (rhann at rationalcommerce dot com)
Rational Commerce Ltd.
<a rel="nofollow" style='text-decoration: none;' href="http://www.rationalcommerce.com" target="_blank">www.rationalcommerce.com</a>
"Ingres development, tuning, and training experts"
FAQ
Search
Profile
Private Messages
Log in
