Hi,
The issue is that the xmlrpc library launches a thread for each client
connection. Nothing prevents these threads from then contacting a
central pool of decoder threads.
Kenneth
On 03/06/14 11:09, Barry Haddow wrote:
> 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
>> [email protected]
>> http://mailman.mit.edu/mailman/listinfo/moses-support
>>
>
>
_______________________________________________
Moses-support mailing list
[email protected]
http://mailman.mit.edu/mailman/listinfo/moses-support
