Hello, I have checked in changes to return fresh XDIReader and XDIWriter instances instead of singletons.
Markus On Fri, May 21, 2010 at 7:44 PM, Markus Sabadello <[email protected]>wrote: > Hello Sergey, > > On Fri, May 21, 2010 at 4:13 PM, Sergey Lyakhov > <[email protected]>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 > > >
_______________________________________________ higgins-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/higgins-dev
