...
List of TMs | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Purpose | Returns JSON list of TMs | |||||||||
Request | GET /%service%/ | |||||||||
Params | - | |||||||||
Returns list of open TMs and then list of available(excluding open) in the app.
|
Create TM | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Purpose | Creates TM with the provided name(tmd and tmi files in/MEM/ folder) | |||||||||
Request | Post /%service%/%tm_name%/ | |||||||||
Params | Required: name, sourceLang | |||||||||
|
Create/Import TM in internal format | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
Purpose | Import and unpack base64 encoded archive of .TMD, .TMI, .MEM(in pre 0.5.x versions) files. Rename it to provided name | |||||||||
Request | POST /%service%/ | |||||||||
Params | { "name": "examle_tm", "sourceLang": "bg-BG" , "data":"base64EncodedArchive" } | |||||||||
Do not import tms created in other version of t5memory. Starting from 0.5.x tmd and tmi files has t5memory version where they were created in the header of the file, and different middle version(0.5.x) or global version(0.5.x) would be represented as This would create example_tm.TMD(data file) and example.TMI(index file) in MEM folder Starting from 0.6.52 import in internal format supporst multipart/form data, so you can send then both file and json_body. In json_body only "name" attribute is required(sourceLang would be ignored anyway). Send it in a same way as streaming import TMX. Json body should be in pretty formatting and in a part called json_body to be parsed correctly.
|
...
Testing TCP backlog options | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
related to | issue T5TMS-281 | |||||||||
most up-to-date version for this ticket is 0.6.75, where there are new flags and functionality to manipulate tcp stack. --add_premade_socket - this is used to create socket and bind it to proxygen server instead of just providing ip address tot the server to open socket inside, should be set to true to enable, log_tcp_backog_events and socket_backlog flags --log_tcp_backog_events if set to true allow to test tcp backog, for that also recomended to set --v=2 --t5loglevel=4. Require add_premade_socket to be set to true. You would see then in logs behaviour of tcp backlog --socket_backlog is simillar to http_listen_backlog, but for socket. But this require add_premade_socket to be set to true --limit_num_of_active_requests, this would limit num of requests that could be handled at the same time in a way, when only n-1 of n created worker threads could be executed at the same time. last one would send 503 error and message that service is busy. I think that it make sense to play with num of worker threads and measure performance, for example try service with 32 threads on 8 cores. in that case service would handle properly 31 thread but 32nd would be responded with error. --debug_sleep_in_request_run just make sleep n microseconds(1/1000000 s) in every requests to artificially slow them down. to test behaviour of tcp backlog you can use attached python script via command: to test tcp backlog you can set --add_premade_socket=1 --t5loglevel=4 --v=2 --debug_sleep_in_request_run=10000000 --log_tcp_backog_events=true --log_every_request_end=1 --log_every_request_start=1 --http_listen_backlog=4 --socket_backlog=2 and other flags as you wish This would make every request at least 10 sec longer, every tcp backlog action would be logged, and also start and end of request handler execution, proxygens http tcp backog would be set to 4(or set it to some other value), and sockets backlog to 2 other approach is to set docker containers environment, but seems like it's also just a hint and could be ignored by os
|