Hi I agree that it's a bad design, but I'm not clear if it can be fixed without changing to a different xmlrpc library
cheers - Barry On 06/03/14 18:40, Kenneth Heafield wrote: > Hi, > > In my view, the threading design of the server is a bug. How about a > producer-consumer queue with multiple producers (a client connection) > and consumers (decoding threads). Each client connection owns a > producer-consumer queue as a return channel so that decoder threads can > return their result. Or we could use boost futures. > > Kenneth > > On 03/06/14 10:30, Barry Haddow wrote: >> Hi Marcos >> >> I think the problem is that the rules (or phrase pairs) are now cached >> on a per thread basis. This is good for command-line Moses as it uses a >> pool of threads, and having per-thread caches means that there is no >> locking on the caches, as there used to be. >> >> mosesserver, afaik, creates a new thread for each connection, so it >> can't take advantage of the cache. This is done in the xmlrpc-c library >> so we don't have much control over it. If you dig around in the xmlrpc-c >> documentation (or code!) you might find a way to control the threading >> policy. >> >> I just spoke to Marcin about the problem, and we're not sure if loading >> the compact phrase table into memory would help, as you still would need >> the higher level cache (in PhraseDictionary). But you could try this anyway. >> >> cheers - Barry >> >> On 06/03/14 17:20, Marcos Fernandez wrote: >>> Hi, I am having an issue with MosesServer. >>> >>> I am using compact phrase and reordering table, and KENLM. >>> >>> The problem is this (I'll explain with an example): >>> >>> - I have one file with 20 very short sentences. I split and tokenize >>> them and send one XMLPRC request per sentence to MosesServer >>> - If I create just one XMLRPC ServerProxy instance and I use it to send >>> all the requests through it, all the sentences get translated in approx >>> 2.5 sec. The problem is that the first sentence takes almost 2 seconds >>> to get translated, while the other 19 are much faster >>> - If I create one ServerProxy instance per request, the translation time >>> rises to 30 sec (now every sentence takes almost 2 sec) >>> >>> I don't understand the reason of that delay for the first request. I >>> have followed the source of this delay to the function: >>> >>> GetTargetPhraseCollectionLEGACY(const Phrase& src) >>> >>> in the file: ...TranslationModel/PhraseDictionary.cpp >>> >>> It seems that for the first request it's needed to look for something >>> in the phrase table, while for subsequent requests it can be retrieved >>> (most of the times) from a cache. >>> >>> But, as the sentences in my file are not related one to another in any >>> way, the information on this cache can not be sentence-dependent, so why >>> wouldn't it be possible for the cache to be preloaded with the >>> information needed? >>> >>> I think that perhaps I have something misconfigured, because I have seen >>> other people using the approach of creating one ServerProxy object for >>> each XMLRPC request (which would facilitate things a lot for me), so I >>> don't think they are experiencing this overhead. Perhaps using the >>> compact formats can have something to do with it? >>> >>> Any help would be much appreciated. I paste below my moses.ini, if that >>> helps: >>> >>> Thanks :) >>> >>> ### MOSES CONFIG FILE ### >>> ################### >>> >>> # input factors >>> [input-factors] >>> 0 >>> >>> # mapping steps >>> [mapping] >>> 0 T 0 >>> >>> # translation tables: table type (hierarchical(0), textual (0), binary >>> (1)), source-factors, target-factors, number of scores, file >>> # OLD FORMAT is still handled for back-compatibility >>> # OLD FORMAT translation tables: source-factors, target-factors, number >>> of scores, file >>> # OLD FORMAT a binary table type (1) is assumed >>> [ttable-file] >>> 12 0 0 5 /opt/moses-compiling/modelos/es-en/phrase-model/phrase-table >>> >>> # no generation models, no generation-file section >>> >>> # language models: type(srilm/irstlm), factors, order, file >>> [lmodel-file] >>> 8 0 5 >>> /opt/moses-compiling/modelos/es-en/lm/13-19-03gen_intec_head8m_sb5LM.kenlm >>> >>> >>> # limit on how many phrase translations e for each phrase f are loaded >>> # 0 = all elements loaded >>> [ttable-limit] >>> 10 >>> >>> # distortion (reordering) files >>> [distortion-file] >>> 0-0 wbe-msd-bidirectional-fe-allff 6 >>> /opt/moses-compiling/modelos/es-en/phrase-model/reordering-table >>> >>> # distortion (reordering) weight >>> [weight-d] >>> 0.097107 >>> 0.150373 >>> -0.0551767 >>> -0.0307787 >>> 0.114613 >>> 0.214587 >>> 0.0467398 >>> >>> # language model weights >>> [weight-l] >>> 0.0442748 >>> >>> >>> # translation model weights >>> [weight-t] >>> 0.00370888 >>> 0.0425665 >>> 0.0719956 >>> 0.0202699 >>> 0.071147 >>> >>> # no generation models, no weight-generation section >>> >>> # word penalty >>> [weight-w] >>> 0.0366626 >>> >>> [distortion-limit] >>> 6 >>> >>> [v] >>> 0 >>> >>> >> > _______________________________________________ > Moses-support mailing list > Moses-support@mit.edu > http://mailman.mit.edu/mailman/listinfo/moses-support > -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336. _______________________________________________ Moses-support mailing list Moses-support@mit.edu http://mailman.mit.edu/mailman/listinfo/moses-support
