Обсуждение: logging or debugging to report time to establish a database connection
I was recently asked how long it takes for postgres (or in my case pgbouncer) to create a database connection and could not find a way within postgres logging or psql to report this information.
I came across depesz's great article on pgbouncer utilizing tcpdump: http://www.depesz.com/2012/12/02/what-is-the-point-of-bouncing/ but Im not familiar with tcpdump and was hoping there was a way to see this using postgres tools.
Is there something I am overlooking in postgres logging or psql client switches that would make this information available or am I stuck with lower level tools?
On Jul 12, 2013, at 9:00 AM, Mike Broers wrote: > Is there something I am overlooking in postgres logging or psql client switches that would make this information availableor am I stuck with lower level tools? Well, if you want to log how long pgbouncer takes to hand out a connection from a pool, you're certainly not going to findthat answer anywhere in postgresql logging ;-) Unfortunately, it doesn't look to me as though the pgbouncer console will show you exactly that. Maybe using -v or -vv optionswould help? But yes, average/max/min maybe even stddev of time to hand out a connection would seem to be informationthat would be good to collect, so perhaps a feature request is in order... Of course there will also be overhead in the libraries that will vary from one database manager to another, so in my opinionthe only way to really benchmark this would be from the client side anyway. Which is maybe what you were thinkingwhen asking about psql switches? Again, a feature request might be in order--I can think of two possibilities: 1)a command-line verbose-mode switch that would provide details of the connection process, which could be good also for debuggingconnection problems, showing what host is being attempted, what the resolution (if any) of the host name is, connectionopened or not, authentication passed or not, and so on; 2) enhancements to the /conninfo command to provide moredetails. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice
BTW, just for the heck of it, I decided to try it out on my dev system (several year old 17" MacBook Pro, meaning core i7processor), PostgreSQL 9.2, pgbouncer 1.5. So, connecting via libpq to postgres directly takes 2-3 ms, connecting to pgbouncertakes typically 70-150 us, with the occasional outlier at 500+ us--of course that's with a pgbouncer config witha big enough pool that I never have to wait for a connection to become free. On Jul 12, 2013, at 9:21 AM, Scott Ribe wrote: > On Jul 12, 2013, at 9:00 AM, Mike Broers wrote: > >> Is there something I am overlooking in postgres logging or psql client switches that would make this information availableor am I stuck with lower level tools? > > Well, if you want to log how long pgbouncer takes to hand out a connection from a pool, you're certainly not going to findthat answer anywhere in postgresql logging ;-) > > Unfortunately, it doesn't look to me as though the pgbouncer console will show you exactly that. Maybe using -v or -vvoptions would help? But yes, average/max/min maybe even stddev of time to hand out a connection would seem to be informationthat would be good to collect, so perhaps a feature request is in order... > > Of course there will also be overhead in the libraries that will vary from one database manager to another, so in my opinionthe only way to really benchmark this would be from the client side anyway. Which is maybe what you were thinkingwhen asking about psql switches? Again, a feature request might be in order--I can think of two possibilities: 1)a command-line verbose-mode switch that would provide details of the connection process, which could be good also for debuggingconnection problems, showing what host is being attempted, what the resolution (if any) of the host name is, connectionopened or not, authentication passed or not, and so on; 2) enhancements to the /conninfo command to provide moredetails. > > > -- > Scott Ribe > scott_ribe@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > > > > -- > Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-admin > -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice
On Jul 12, 2013, at 9:59 AM, Mike Broers wrote: > Thanks, did you use tcpdump to determine that? I'm happy to learn a new tool (to me), but wanted to make sure I wasntoverlooking something at my disposal within postgres. When I said "connecting via libpq" I meant I inserted timers in some C code, and looped through some calls to PQconnectdb. -- Scott Ribe scott_ribe@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice