Martijn van Oosterhout wrote:
On Mon, Mar 27, 2006 at 10:57:21AM +0200, Thomas Hallgren wrote:
Martijn,
I tried a Socket approach. Using the new IO stuff that arrived with Java
1.4 (SocketChannel etc.), the performance is really good. Especially on
Linux where an SMP machine show a 1 to 1.5 ratio between one process doing
ping-pong between two threads and two processes doing ping-pong using a
socket. That's acceptable overhead indeed and I don't think I'll be able to
trim it much using a shared memory approach (the thread scenario uses Java
monitor locks. That's the most efficient lightweight locking implementation
I've come across).
Yeah, it's fairly well known that the distinctions between processes
and threads on linux is much smaller than on other OSes. Windows is
pretty bad, which is why threading is much more popular there.
The real downside is that a call from SQL to PL/Java using the current
in-process approach is really fast. It takes about 5 micro secs on my
2.8GHz i386 box. The overhead of an IPC-call on that box is about 18 micro
secs on Linux and 64 micro secs on Windows. That's an overhead of between
440% and 1300% due to context switching alone. Yet, for some applications,
<snip>
This might take some more measurements but AIUI the main difference
between in-process and intra-process is that one has a JVM per
connection, the other one JVM shared. In that case might thoughts are
as follows:
- Overhead of starting JVM. If you can start the JVM in the postmaster
you might be able to avoid this. However, if you have to restart the
JVM each process, that's a cost.
- JIT overhead. For often used classes JIT compiling can help a lot
with speed. But if every class needs to be reinterpreted each time,
maybe that costs more than your IPC.
- Memory overhead. You meantioned this already.
- Are you optimising for many short-lived connections or a few
long-lived connections?
My gut feeling is that if someone creates a huge number of server-side
java functions that performence will be better by having one always
running JVM with highly JIT optimised code than having each JVM doing
it from scratch. But this will obviously need to be tested.
The use case with a huge number of short-lived connections is not feasible at all with
PL/Java as it stands today. This is partly the reason for my current research. Another
reason is that it's sometimes desirable to share resources between your connections.
Dangerous perhaps, but an API that encourages separation and allows sharing in a controlled
way might prove very beneficial.
The ideal use-case for PL/Java is a client that utilizes a connection pool. And most servlet
containers and EJB servers do. Scenarios where you have just a few and fairly long lived
clients are OK too.
One other thing is that seperate processes give you the ability to
parallelize. For example, if a Java function does an SPI query, it can
receive and process results in parallel with the backend generating
them. This may not be easy to acheive with an in-process JVM.
It is fairly easy to achieve using threads. Only one thread at a time may of course execute
an SPI query but that's true when multiple processes are in place too since the backend is
single-threaded, and since the logical thread in PL/Java must utilize the same backend as
where the call originated (to maintain the transaction boundaries). Any result must also
sooner or later be delivered using that same backend which further limits the ability to
parallelize.
Incidently, there are compilers these days that can compile Java to
native. Is this Java stuff setup in such a way that you can compile your
classes to native and load directly for the real speed-freaks?
PL/Java can be used with GCJ although I don't think the GCJ compiler outranks the JIT
compiler in a modern JVM. It can only do static optimizations whereas the JIT has runtime
heuristics to base its optimizations on. In the test results I've seen so far, the GCJ
compiler only gets the upper hand in very simple tests. The JIT generated code is faster
when things are more complicated.
GCJ is great if you're using short-lived connections (less startup time and everything is
optimized from the very start) but the native code that it produces still needs a JVM of
some sort. No interpreter of course but classes must be initialized, a garbage collector
must be running etc. The shared native code results in some gain in memory consumption but
it's not as significant as one might think.
In that
case, maybe you should concentrate on relibility and flexibility and
still have a way out for functions that *must* be high-performance.
Given time and enough resources, I'd like to provide the best of two worlds and give the
user a choice whether or not the JVM should be external. Ideally, this should be controlled
using configuration parameters so that its easy to test which scenario that works best. It's
a lot of work though.
It very much comes down to your point "Are you optimising for many short-lived connections
or a few long-lived connections?"
If the use-cases for the former are fairly few then I'm not sure it's worth the effort. In
my experience, that is the case. People tend to use connection pools nowadays. But that's me
and my opinion. It would be great if more people where involved in this discussion.
Regards,
Thomas Hallgren
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
http://archives.postgresql.org
