Skip site navigation (1) Skip section navigation (2)

Re: Large difference between elapsed time and run time

From: "Jeffrey D(dot) Brower" <jeff(at)pointhere(dot)net>
To: "Nikk Anderson" <Nikk(dot)Anderson(at)parallel(dot)ltd(dot)uk>,"'Scott Buchan'" <sbuchan(at)technicacorp(dot)com>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Large difference between elapsed time and run time
Date: 2003-03-11 14:24:20
Message-ID: 00fb01c2e7d9$e804bfa0$0b02a8c0@pointhere.net (view raw or flat)
Thread:
Lists: pgsql-performance
RE: [PERFORM] Large difference between elapsed time and run time for queriesExcuse me for butting into this conversation but I would LOVE to know exactly how you manage that pooling because I have this same issue.  When I run a test selection using psql I get sub-second response time and when I use the online (a separate machine dedicated to http) and do a pg_connect to the database using PHP4 I hit 45-50 second response times.  I even tried changing the connection to a persistent connection with pg_pconnect and I get the same thing.  I installed the database on the http machine and the responses are much quicker, but still not quite ideal.

My question is how are you accomplishing the connection pooling?

     Jeff 
  ----- Original Message ----- 
  From: Nikk Anderson 
  To: 'Scott Buchan' ; pgsql-performance(at)postgresql(dot)org 
  Sent: Tuesday, March 11, 2003 3:46 AM
  Subject: Re: [PERFORM] Large difference between elapsed time and run time 


  Hi, 

  I have noted similar issues in the past - and seemed then that most of the overhead bottleneck was due to establishing a new connection in the front end.  As soon as I started using connection pooling, with connections made when the app initialises, and then recycled for each request (i.e. the connections never close) then the execution time was far quicker. 

  I have also noticed that sparc processor speed, num processors, disk space and memory seems to makes little difference with postgres (for us anyway!) performance - e.g. performance no better with dual sparc 450mhz, 2 scsi disks, 1Gb mem - than on a single processor 400 mhz Netra, 256Mb ram with a single IDE disk!

  Nikk 

  -----Original Message----- 
  From: Scott Buchan [mailto:sbuchan(at)technicacorp(dot)com] 
  Sent: 10 March 2003 18:58 
  To: pgsql-performance(at)postgresql(dot)org 
  Subject: [PERFORM] Large difference between elapsed time and run time for queries 



  Hello, 

  While running benchmarks for my database, I am seeing a large difference in the elapsed time (from stats collected in the logs) and run time (running explain analyze on the query using ./psql <database>) for each of my queries.  The database is being ran on a sunfire 880 with 4 750mhz processors with 8 G RAM running solaris 8

  I am simulating 200 user connections each running 6 select queries on 1 indexed table with 50,000 records. The elapsed time for the queries average around 2.5 seconds while if I run the query using explain analyze while the test is running, the run time is around 300 ms although it takes much longer (few seconds) to display the results.  If I reduce the number of concurrent connections to 100 then the run time and elapsed time for the queries are the same.

  I have tried numerous configurations in the postgresql.conf file.  I have set the shared_buffers with values ranging from 75 MB to 4000MB with no luck.  I have also tried increasing the sort_mem with no luck.



  When the test is running, the cpu is well over 50% idle and iostat shows that the processes are not waiting for i/o and disk usage percentage is low.

  Any help would be appreciated. 

  Thanks. 

In response to

Responses

pgsql-performance by date

Next:From: Nikk AndersonDate: 2003-03-11 14:30:45
Subject: Re: Large difference between elapsed time and run time
Previous:From: Nikk AndersonDate: 2003-03-11 08:46:32
Subject: Re: Large difference between elapsed time and run time

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group