Bug 5044 - tlstunnel has an annoyingly long command line
Summary: tlstunnel has an annoyingly long command line
Status: CLOSED FIXED
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Misc (show other bugs)
Version: trunk
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.6.0
Assignee: Pierre Ossman
URL:
Keywords: prosaic, samuel_tester
Depends on:
Blocks:
 
Reported: 2014-03-27 09:33 CET by Pierre Ossman
Modified: 2016-04-14 14:17 CEST (History)
2 users (show)

See Also:
Acceptance Criteria:


Attachments

Description Pierre Ossman cendio 2014-03-27 09:33:03 CET
Just look at this monster:

/opt/thinlinc/libexec/tlstunnel --port 300 --sock /var/run/thinlinc/tlwebaccess-notls.sock --tls-sock /var/run/thinlinc/tlwebaccess-tls.sock --cert /opt/thinlinc/etc/tlwebaccess/server.crt --certkey /opt/thinlinc/etc/tlwebaccess/server.key --logname tlwebaccess

Very annoying when doing ps listings.

Possible solutions:

 1. Send parameters as environment variables instead.

 2. Give tlstunnel the ability to read config files.

 3. Make most of the stuff implicit. So you would have:

    /opt/thinlinc/libexec/tlstunnel --port 300 --service tlwebaccess

    And from that you would have implied things like:

    /var/run/thinlinc/tls/<service>.sock
    /opt/thinlinc/etc/<service>.crt
    /opt/thinlinc/etc/<service>.key
Comment 3 Pierre Ossman cendio 2015-03-06 13:18:34 CET
Bug 5463 probably makes the performance overhead on Solaris negligible.
Comment 5 Pierre Ossman cendio 2015-09-07 12:56:23 CEST
I'v done some performance tests using the new code. I've used the stress test script from bug 765 and changed it to do simple GET requests.

Threads: 30
Requests: 110 (total, not per thread)

Test machine: Virtual RHEL 7 with 2 CPUs

URI                      Before           After          Difference
/images/cendio_logo.png  ~260 ms/req      ~290 ms/req    +12%
/main/                   ~2000 ms/req     ~1900 ms/req   -5%

So a bit slower for short requests, but no real difference for longer requests.

If I give the machine more CPUs, allowing more parallel work, I get these numbers:

URI                      Before           After          Difference
/images/cendio_logo.png  ~260 ms/req      ~260 ms/req    0%
/main/                   ~510 ms/req      ~560 ms/req    +10%

Oddly enough, the longer request is seeing more of a difference here. Might just be statistical noise.

A serial test (1 thread, 20 requests) gives this:

URI                      Before           After          Difference
/images/cendio_logo.png  ~40 ms/req       ~50 ms/req     +25%
/main/                   ~150 ms/req      ~160 ms/req    +7%

Here we can more clearly see that the overhead is fairly stable at 10 ms per request.
Comment 16 Pierre Ossman cendio 2016-02-09 16:26:09 CET
That should be it.

Tester should verify that tlwebaccess and tlwebadm are still able to communicate TLS properly. Tester should also verify the logging looks sane (may need to turn it up to DEBUG to get output from tlstunnel).
Comment 18 Samuel Mannehed cendio 2016-02-16 17:42:25 CET
Tested with build 5034, Fedora 23 server

I have verified that both tlwebaccess and tlwebadm still works properly during normal usage. Logging looks good albeit being quite wordy. But I guess that's what to expect when using DEBUG. I have tested using Firefox 44 and Chrome 49 Beta on Linux, and Chrome 47 and Microsoft Edge on Windows 10.

Note You need to log in before you can comment on or make changes to this bug.