OTP Server Setup

[Thânia Clair de Souza Vargas]

Hello!

I've been testing the OpenTripPlanner platform for a while and I was wondering the ideal server configuration to run it. I have my own OTP running in my server with the Portland graph and it runs quite well when I play around with it. However, when I test it with 5 users per second simultaneously (JMeter), I receive responses only after 20-50 seconds. I do the same test with Trimet OTP and even with many users simultaneously, their response is very quick always - a little more than one second. I use 20g of memory to run the servlet application server. What am I missing? Someone knows the server configuration of Trimet to get that great performance?

Looking forward to hearing from someone.

Thank you!

Thânia Vargas.

[Andrew Byrd]

Hi Th�nia,

The first thing to do is make sure you have given the Java virtual
machine enough memory. If in doubt, use VisualVM to observe and check
that it has some "breathing room" since OTP tends to create then destroy
huge blocks of objects at each request, an operation which Java garbage
collector can do quite efficiently if it has enough working space.

The most likely explanation for your problem is that OTP (as a servlet)
will naturally try to service all incoming requests in parallel, one
thread per request. This is a decent policy for typical I/O intensive
tasks, but OTP requests are atypical in that they use a lot of memory
and processor time, which combine additively when you try to do a
several tasks at the same time.

The solution is to limit the number of request handling threads in your
servlet container to roughly the number of processor cores available on
the machine, and increase the connection queue length (see maxThreads
attribute at http://tomcat.apache.org/tomcat-5.5-doc/config/http.html).
Then observe memory consumption using VisualVM with the VisualGC plugin
while handling your N requests in parallel, and make sure the JVM still
has enough heap space to work efficiently on that many requests
simultaneously. You generally want to avoid triggering garbage
collection during a request -- a good GC pattern is to see Eden space
use increase by something like a 1/nthreads fraction of the total Eden
space during an individual request. In this case JVM has an easy time
throwing away all the temporary objects.

I believe TriMet has a more sophisticated system with a load balancer
and several servers, so your 5 reqeusts are probably not going to the
same machine.

-Andrew

> Th�nia Vargas.
>
> --
> You received this message because you are subscribed to the Google
> Groups "OpenTripPlanner Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to opentripplanner-...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>