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
Bug 5463 probably makes the performance overhead on Solaris negligible.
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.
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).
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.
