On Fri, May 21, 2010 at 4:13 PM, Sergey Lyakhov
<slyakhov@xxxxxxxxxxxxxx> wrote:
Markus,
I've profiled/debugged PDS service and found two bottlenecks in XDI4J:
1. The most part of processing time takes xdi4j.xri3.impl.parser.Parser, see attached 1_thread.html.
However this is a class generated from ABNF, and I am not sure there is a way to significantly increase its performance.
Yes I agree this is probably not possible..
The only option here would be to use String instead of XRI3Segment, but this would have big implications on the entire library, because in some places the functionality of XRI3Segment is really needed.
2. XDI has multithreading problems. The time of processing for parallel threads increases linearly
the number of threads (see attached 5_threads.html and 10_threads.html).
This occurs because XDIReaderRegistry contains singleton readers, which, in turn, are not thread-safe and
contain synchronized method read(). So, all threads in EndpointServlet.readFromBody() method get the same singleton
instance of XDIReader from XDIReaderRegistry and wait on its read() method. We can try to fix that by changing
XDIReaderRegistry to return a new instance of reader instead of singleton.
The reason why I used singletons was that I thought it's better to re-use the reader objects instead of creating/destroying them all the time. But yes, maybe I was wrong and its better to return new instances for every read operation.
Another thing to make sure is that the client sets the header Content-Type: text/xdi+x3, so that the XDI server uses the X3StandardReader instead of the AutoReader, but I think this is happening already.
Out of curiosity, what software did you use for profiling?
Markus
Thanks,
Sergey Lyakhov
