[Paraview] PV in client-server mode seems slower than standalone

Berk Geveci berk.geveci at gmail.com
Mon Jul 3 10:08:50 EDT 2006


Hi Peter,

What are your 3D view settings? Also, what is the size of your dataset and
the geometry you have generated? Fine-tuning client/server performance is a
form of art, I am finding out :-) Usually, there are two different extremes
when running in client/server mode:

1. Large geometry, cannot be rendered by a single node
2. Small to medium size geometry, can be rendered by a single node much
faster than server

In the first case, there is no choice. The geometry has to be rendered on
the server. Therefore each render has to follow these steps:

1. Client tells server to start rendering (*)
2. Client sends camera information (*)
3. Client starts waiting for progress
4. Server starts rendering
5. Server sends progress (repeat until rendering is done) (*)
6. Server sends final image to client (*)
7. Client renders image

* Communication over TCP/IP

In this situation, the potential bottlenecks are
1. All the communication over TCP/IP
2. Rendering performance of the server

If the server is not equipped with a decent graphics card, it may render
much more slowly than client. Sometimes, there is no alternative because the
geometry is too large to render on the client.

Solutions:

To reduce client/server communication, reduce the size of the image that is
sent to client either through compression or size reduction. In 3D view
settings, adjust:
* Subsample rate (size reduction)
* Squirt compression

Note that these settings only impact the interactive rendering. The final
render after you release the mouse will not be impacted.

In the second case, you have to tell ParaView that you want client to do the
rendering instead of the server.  This is done by adjusting the composite
threshold on the 3D view settings page. The threshold is the size of all
geometry in MBytes. If the size of geometry is above the thresold, the
geometry is rendered on the server and delivered to the client. If below,
the geometry itself is delivered to the client and is rendered locally. It
is also possible to disable compositing alltogether. If ParaView detects
that the server cannot render (no DISPLAY set for example), it will disable
compositing automatically (as of 2.4.3, I believe).

Potential bottlenecks:
1. Geometry is too large and client cannot render geometry fast
2. Geometry has to be delivered to client everytime filter(s) re-execute,
this usually happens only after Accepting
3. An existing bug causes ParaView to tell the server to start sending
progress during each render. This is a no-op but still cause TCP/IP
communication. This is only relevant if the client/server connection is slow

There is also a hybrid mode. ParaView can use a reduced geometry model
during interaction. This is controlled by the LOD threshold and LOD
resolution on the 3D view settings. It is possible to adjust the 3D view
settings such that the LOD is small enough to be rendered locally and the
full geometry is rendered on the server. Using this, you can get the best of
both worlds (in theory).

We have plans to make ParaView smarter and make some choices for the user
based on the frame rates.

On top of all of the above, there are bottlenecks arising from the fact that
everytime a parameter changes, it has to be sent from client to server over
TCP/IP. If a response is requested, event handling is disabled until it
arrives. This causes some choppiness of the GUI.

Without knowing exactly what you mean by leses responsive, this is all I can
say (which is a lot, I guess) :-)

-Berk




On 6/30/06, Peter J. Bismuti <pjb9508 at vashon.ca.boeing.com> wrote:
>
> I have a small dataset that I'm inspecting using client-server
> mode.  However,
> it seems far less responsive than when I was running it in a single
> process.
> Am I doing something incorrect?
>
> Thanks
>
>
> -bash-3.00$ bin/pvserver
> Listen on port: 11111
> Waiting for client...
> connected to port 11111
> Client connected.
>
> -bash-3.00$ pvclient -sh=skagit
> Connect to skagit:11111
>
>
> _______________________________________________
> ParaView mailing list
> ParaView at paraview.org
> http://www.paraview.org/mailman/listinfo/paraview
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://public.kitware.com/pipermail/paraview/attachments/20060703/e88e7221/attachment.html


More information about the ParaView mailing list