From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Andrej <andrej(dot)groups(at)gmail(dot)com> |
Cc: | Dimitri Fontaine <dimitri(at)2ndquadrant(dot)fr>, c k <shreeseva(dot)learning(at)gmail(dot)com>, Chris Travers <chris(dot)travers(at)gmail(dot)com>, Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>, pgsql-general(at)postgresql(dot)org, sad(at)bestmx(dot)ru |
Subject: | Re: Using Postgresql as application server |
Date: | 2011-08-28 15:13:52 |
Message-ID: | CAHyXU0z2Fa_Mxe9C4D1G-+qLxpsFRv0uZbWc-To0F4q+7FDTfQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-admin pgsql-general |
On Sat, Aug 27, 2011 at 11:43 PM, Andrej <andrej(dot)groups(at)gmail(dot)com> wrote:
> On 19 August 2011 04:16, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
>>> It's been around for a long time already:
>>>
>>> http://asmith.id.au/mod_libpq.html
>> mod_libpq looks like it hasn't been updated in quite a while (apache
>> 1.3 only) -- I think a node.js http server is superior in just about
>> every way for this case. I 100% agree with the comments on the page
>> though.
>
> Tad late to chime in, but mod_libpq2.c is available from the good
> man, too.
> http://asmith.id.au/source/mod_libpq2.c
>
> Compiles & installs fine on Slackware64 13.1:
> sudo /usr/sbin/apxs -i -a -c -I /usr/include/postgresql/ -I
> /usr/include/httpd -lpq -o mod_libpq.so -n MOD_LIBPQ mod_libpq2.c
> using postgresql 9.0.4 & apache 2.2.19
Sure -- but these days if I were trying to run a setup like this
through a classic web server, I think a small fastcgi wrapper is a
better way to go. It's simpler, gives you a cleaner approach to
hooking in your on stuff like a connection pool, and is portable
across web servers. ISTM lighttpd and nginx are lighter weight and
designed for this type of serving. In apache, you have mod_fastcgi
which is probably a better abstraction to use than mod_libpq. You also
have a much wider audience for your code if you chose to advance your
wrapper as a library.
node.js is even thinner. instead of running your requests through
fastcgi, node.js is a simple protocol server that runs the web request
in the server thread itself, including your libpq bindings, connection
pool, etc. This is why as long as you are not doing to much work in
the javascript itself, it could very well prove to be the most
scalable solution with the lowest latency response times without
resorting to a hand rolled http server in C. node.js is single
threaded and 100% asynchronous which fits very nice with libpq which
is at heart a single threaded asynchronous library. Client side
connection pooling is trivial in single threaded engines such that a
middle of the road programmer could rig up an ad hoc implementation
quickly and effectively, very complex otherwise.
merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2011-08-28 17:09:41 | Re: Using Postgresql as application server |
Previous Message | Craig Ringer | 2011-08-28 13:43:37 | Re: What is postgresql status? I'm not sure |
From | Date | Subject | |
---|---|---|---|
Next Message | Ian Pilcher | 2011-08-28 16:23:56 | Re: JDBC Connection Errors |
Previous Message | Craig Ringer | 2011-08-28 13:33:26 | Re: JDBC Connection Errors |