Hi heikki,
First of all a big thanks for your reply .
From server side query are not taking much time I have checked that .
But from the client side when i am executing Nhibernate.doload() , doloadbyclass() functions
it is taking much of the CPU time .
This i have analyzed by YOURKIT profiler for .Net applications .
Most of the CPU time is taken by Nhibernate.doload() , doloadbyclass() functions and i believe internally they are
calling System.Net.Sockets.Socket.Poll(Int32, SelectMode) function .
So my big worry is why Nhibernate.DoLoad() , DoLoadByClass is taking much of the time ?
Is there any Nhibernate related config file got changed ? or what are the most probale places for this problem so that i can look for them.
Apart from this i want to ask one more question .
In one machine it calls NPGSQLconnectorpool.
GetNonpooledConnector()and in other machien it callse NPGSQLconnectorpool.
GepooledConnector()
Does calling pool and nonpool version of methods make a big difference ?
Thanks ,
Keshav
On Fri, Oct 16, 2009 at 2:20 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
keshav upadhyaya wrote:
> 2- Internally it calls thse function i am listing the last stack
>
> NpgsqlConnector.Open()
> Npgsql.NpgsqlConnectedState.Startup(NpgsqlConnector)
> Npgsql.NpgsqlState.ProcessBackendResponses(NpgsqlConnector)
> *[Wall Time] System.Net.Sockets.Socket.Poll(Int32, SelectMode)*
>
> Finally in last the socket.poll takes most of the time .
>
>
> I want to know the probably causes of the socket.poll() consumes allot of
> time .
I don't know much about Npgsql driver, but I'd guess that it's spending
a lot of time on Socket.Poll, because it's waiting for a response from
the server, sleeping. If you're investigating this because you feel that
queries are running too slowly, you should look at what the queries are
and investigate why they're slow in the server, e.g with EXPLAIN
ANALYZE. If you're investigating this because you're seeing high CPU
load in the client, try finding an option in the profiler to measure CPU
time, not Wall time.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
--
Thanks,
Keshav Upadhyaya