FAQ
Hi,

I am using the following example as on the main go docs :
http://golang.org/pkg/net/http/#ListenAndServeTLS

I did a performance check on Windows 7 64 Bit for HTTPS connections and it
is surprising that it really performs badly.
My test methodology is simple, press F5 continously in chrome.
The CPU shot to 25-50% and the RAM also kept on increasing.
During the constant refresh, there are many "Connection was reset"
messages.

As against this the normal ListenAndServe example is very stable. I did an
ab.exe -n 10000 -c 1000 http://127.0.0.1:PORT/index.html and it completes
it in 60-70 seconds. The MAX CPU touches 9-10% and RAM usage increases a
little BIT and after the requests are complete, it reaches near the
previous RAM usage.

Has anyone else experienced this ?
Looking forward to any input to improve performance.

Regards,
Raheel

Search Discussions

  • Jan Mercl at Sep 8, 2012 at 6:14 pm

    On Sat, Sep 8, 2012 at 2:06 PM, wrote:
    I am using the following example as on the main go docs :
    http://golang.org/pkg/net/http/#ListenAndServeTLS

    I did a performance check on Windows 7 64 Bit for HTTPS connections and it
    is surprising that it really performs badly.
    My test methodology is simple, press F5 continously in chrome.
    The CPU shot to 25-50% and the RAM also kept on increasing.
    During the constant refresh, there are many "Connection was reset" messages.
    How this "methodology" rules out the possibility that the effects
    observed are rooted in/caused by the browser instead of the Go server?

    -j
  • Raheelgup at Sep 9, 2012 at 5:45 am
    Hi,

    Because I was using the Process Explorer from SysInternals and tracking the
    CPU and Memory usage of the binary created.
    The 25-40% usage is only in case of ListenAndServeTLS<http://golang.org/pkg/net/http/#ListenAndServeTLS>


    Regards,
    R
    On Saturday, September 8, 2012 11:44:19 PM UTC+5:30, Jan Mercl wrote:
    On Sat, Sep 8, 2012 at 2:06 PM, <rahe...@gmail.com <javascript:>> wrote:
    I am using the following example as on the main go docs :
    http://golang.org/pkg/net/http/#ListenAndServeTLS

    I did a performance check on Windows 7 64 Bit for HTTPS connections and it
    is surprising that it really performs badly.
    My test methodology is simple, press F5 continously in chrome.
    The CPU shot to 25-50% and the RAM also kept on increasing.
    During the constant refresh, there are many "Connection was reset"
    messages.

    How this "methodology" rules out the possibility that the effects
    observed are rooted in/caused by the browser instead of the Go server?

    -j
  • Agl at Sep 9, 2012 at 4:43 pm

    On Sunday, September 9, 2012 1:45:49 AM UTC-4, rahe...@gmail.com wrote:

    Because I was using the Process Explorer from SysInternals and tracking
    the CPU and Memory usage of the binary created.
    The 25-40% usage is only in case of ListenAndServeTLS<http://golang.org/pkg/net/http/#ListenAndServeTLS>

    Getting connection errors is concerning, that shouldn't happen. The
    following produces a perfectly stable server for me (on Linux):

    $ openssl genrsa 1024 > key.pem
    $ openssl req -new -x509 -key key.pem -out cert.pem -days 1095
    $ cat t.go
    package main

    import (
    "net/http"
    )

    func main() {
    err := http.ListenAndServeTLS(":8081", "cert.pem", "key.pem", nil)
    if err != nil {
    panic(err)
    }
    }
    $ go run t.go

    I can hold F5 in Chrome without a glitch and running the follow doesn't
    produce any problems either:

    $ while true; do openssl s_client -tls1 -connect 127.0.0.1:8081 <
    /dev/null; done

    However, while I would generally expect the connection to get reused when
    hitting F5, that doesn't actually seem to happen. So each request is a new
    TLS connection and, as crypto/tls doesn't so session resumption, it's a new
    handshake too. We can add profiling support to the binary to see this:

    $ cat t.go
    package main

    import (
    "net/http"
    "os"
    "runtime/pprof"
    "time"
    )

    func main() {
    f, err := os.Create("profile")
    if err != nil {
    panic(err)
    }
    pprof.StartCPUProfile(f)
    go func() {
    time.Sleep(15 * time.Second)
    pprof.StopCPUProfile()
    println("profile written")
    f.Close()
    }()
    err := http.ListenAndServeTLS(":8081", "cert.pem", "key.pem", nil)
    if err != nil {
    panic(err)
    }
    }

    We can run that and hold F5 for 15 seconds to get a profile.
    (See http://blog.golang.org/2011/06/profiling-go-programs.html for more
    details.)

    (pprof) top10 -cum
    Total: 1075 samples
    0 0.0% 0.0% 827 76.9% schedunlock
    0 0.0% 0.0% 822 76.5% net/http.(*conn).serve
    0 0.0% 0.0% 813 75.6% crypto/tls.(*Conn).Handshake
    0 0.0% 0.0% 813 75.6% crypto/tls.(*Conn).serverHandshake
    2 0.2% 0.2% 578 53.8%
    crypto/elliptic.(*CurveParams).ScalarMult
    0 0.0% 0.2% 495 46.0%
    crypto/tls.(*ecdheRSAKeyAgreement).generateServerKeyExchange
    9 0.8% 1.0% 449 41.8% math/big.nat.div
    135 12.6% 13.6% 431 40.1% math/big.nat.divLarge
    8 0.7% 14.3% 347 32.3% math/big.(*Int).Mod
    2 0.2% 14.5% 343 31.9% math/big.(*Int).QuoRem

    So 75% of the time is being taken in handshaking and the rest is probably
    taken in dealing with the garbage from that.

    You could stand up an OpenSSL based proxy in front of the server and that
    would get you a huge speedup and crypto code that has been extensively
    reviewed (unlike the Go code). If you want to remain pure Go then you can
    get a significant speedup by configuring the CipherSuites member of
    tls.Config to include just TLS_RSA_WITH_RC4_128_SHA
    and TLS_RSA_WITH_AES_128_CBC_SHA. This will exclude ECDHE from the
    handshake, saving a lot of time since I haven't optimised Go's P-256.
    Finally, you could implement SessionTickets in crypto/tls which would speed
    up this test immensely, although the real-world speed up would be less.


    Cheers

    AGL
  • Brainman at Sep 10, 2012 at 4:54 am

    On Monday, 10 September 2012 01:55:14 UTC+10, (unknown) wrote:

    So 75% of the time is being taken in handshaking and the rest is probably
    taken in dealing with the garbage from that.

    Running your test on windows/386 current tip using real network:

    (pprof) top10 -cum
    Total: 803 samples
    0 0.0% 0.0% 785 97.8% schedunlock
    0 0.0% 0.0% 771 96.0% crypto/tls.(*Conn).Handshake
    0 0.0% 0.0% 771 96.0% crypto/tls.(*Conn).serverHandshake
    0 0.0% 0.0% 771 96.0% net/http.(*conn).serve
    1 0.1% 0.1% 503 62.6%
    crypto/elliptic.(*CurveParams).ScalarMult
    0 0.0% 0.1% 500 62.3%
    crypto/tls.(*ecdheRSAKeyAgreement).generateServerKeyExchange
    6 0.7% 0.9% 491 61.1% math/big.nat.div
    220 27.4% 28.3% 479 59.7% math/big.nat.divLarge
    5 0.6% 28.9% 325 40.5% math/big.(*Int).QuoRem
    3 0.4% 29.3% 323 40.2% math/big.(*Int).Mod
    (pprof)

    Alex
  • Raheelgup at Sep 10, 2012 at 7:33 am


    Hi,
    I am on a Windows 7 64 Bit box and I see this CPU issue on Windows.
    I havent tested it on Linux and will do it tomorrow.
    I had created the Certificate using the generate_cert.go and now did it
    with the openssl.exe utility in Apache.
    I still see the CPU shooting very high with a continous F5 in Chrome.
    I will try your suggested methods as well.
    But is there any chance of improvement for this ?

    @brainman what is the CPU usage you see for TLS ?

    Regards,
    R
  • Brainman at Sep 10, 2012 at 7:36 am

    On Monday, 10 September 2012 17:33:40 UTC+10, rahe...@gmail.com wrote:
    @brainman what is the CPU usage you see for TLS ?
    How would you like me to measure it?

    Alex
  • Raheelgup at Sep 10, 2012 at 8:06 am
    Hi,

    If you have ab.exe compiled with SSL then that is the simplest way to do it.
    Otherwise even a CONTINOUS F5 in Chrome is enough to shoot the CPU to
    25-40% when using TLS as the server.

    Regards,
    R
    On Monday, September 10, 2012 1:06:13 PM UTC+5:30, brainman wrote:
    On Monday, 10 September 2012 17:33:40 UTC+10, rahe...@gmail.com wrote:

    @brainman what is the CPU usage you see for TLS ?
    How would you like me to measure it?

    Alex
  • Brainman at Sep 11, 2012 at 1:02 am

    On Monday, 10 September 2012 18:06:20 UTC+10, rahe...@gmail.com wrote:

    If you have ab.exe ...
    I used ab.

    # ab -n 10000 -c 1000 http://alex:8081/index.html
    This is ApacheBench, Version 2.3 <$Revision: 655654
    $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd,
    http://www.zeustech.net/
    Licensed to The Apache Software Foundation,
    http://www.apache.org/


    Benchmarking alex (be
    patient)
    Completed 1000
    requests
    Completed 2000
    requests
    Completed 3000
    requests
    Completed 4000
    requests
    Completed 5000
    requests
    Completed 6000
    requests
    Completed 7000
    requests
    Completed 8000
    requests
    Completed 9000
    requests
    Completed 10000
    requests
    Finished 10000
    requests




    Server
    Software:

    Server Hostname:
    alex
    Server Port:
    8081


    Document Path:
    /index.html
    Document Length: 0
    bytes


    Concurrency Level:
    1000
    Time taken for tests: 4.644
    seconds
    Complete requests:
    10000
    Failed requests:

    Write errors:

    Total transferred: 76811
    bytes
    HTML transferred: 0
    bytes
    Requests per second: 2153.31 [#/sec]
    (mean)
    Time per request: 464.401 [ms]
    (mean)
    Time per request: 0.464 [ms] (mean, across all concurrent
    requests)
    Transfer rate: 16.15 [Kbytes/sec]
    received


    Connection Times
    (ms)
    min mean[+/-sd] median
    max
    Connect: 143 203 65.5 201
    3125
    Processing: 165 224 27.1 225
    271
    Waiting: 5 94 53.5 93
    269
    Total: 320 427 61.1 432
    3332


    Percentage of the requests served within a certain time
    (ms)
    50%
    432
    66%
    433
    75%
    434
    80%
    434
    90%
    436
    95%
    437
    98%
    438
    99%
    438
    100% 3332 (longest
    request)

    Alex
  • Raheelgup at Sep 11, 2012 at 6:41 am
    Hi,

    @Alex, when using ListenAndServeTLS a request to
    http://1270.0.1:8081/index.html is not served at all.
    It just returns the "?" mark character even for the whole page.
    You need to query https://1270.0.1:8081/index.html

    Even a simple F5 is more than enough for this to show you the result in
    windows.
    Linux performance is better no doubt.

    @AGL if you could give me a starter as to how to improve this or some
    guides to the methods you described, I would be very happy.

    Regards,
    R
    On Tuesday, September 11, 2012 6:32:39 AM UTC+5:30, brainman wrote:
    On Monday, 10 September 2012 18:06:20 UTC+10, rahe...@gmail.com wrote:


    If you have ab.exe ...
    I used ab.

    # ab -n 10000 -c 1000 http://alex:8081/index.html

    This is ApacheBench, Version 2.3 <$Revision: 655654
    $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

    Licensed to The Apache Software Foundation, http://www.apache.org/



    Benchmarking alex (be
    patient)
    Completed 1000
    requests
    Completed 2000
    requests
    Completed 3000
    requests
    Completed 4000
    requests
    Completed 5000
    requests
    Completed 6000
    requests
    Completed 7000
    requests
    Completed 8000
    requests
    Completed 9000
    requests
    Completed 10000
    requests
    Finished 10000
    requests




    Server
    Software:

    Server Hostname:
    alex
    Server Port:
    8081


    Document Path:
    /index.html
    Document Length: 0
    bytes


    Concurrency Level:
    1000
    Time taken for tests: 4.644
    seconds
    Complete requests:
    10000
    Failed requests:

    Write errors:

    Total transferred: 76811
    bytes
    HTML transferred: 0
    bytes
    Requests per second: 2153.31 [#/sec]
    (mean)
    Time per request: 464.401 [ms]
    (mean)
    Time per request: 0.464 [ms] (mean, across all concurrent
    requests)
    Transfer rate: 16.15 [Kbytes/sec]
    received


    Connection Times
    (ms)
    min mean[+/-sd] median
    max
    Connect: 143 203 65.5 201
    3125
    Processing: 165 224 27.1 225
    271
    Waiting: 5 94 53.5 93
    269
    Total: 320 427 61.1 432
    3332


    Percentage of the requests served within a certain time
    (ms)
    50%
    432
    66%
    433
    75%
    434
    80%
    434
    90%
    436
    95%
    437
    98%
    438
    99%
    438
    100% 3332 (longest
    request)

    Alex
  • Brainman at Sep 11, 2012 at 8:53 am

    On Tuesday, 11 September 2012 16:41:52 UTC+10, rahe...@gmail.com wrote:
    @Alex, when using ListenAndServeTLS a request to
    http://1270.0.1:8081/index.html is not served at all.
    It just returns the "?" mark character even for the whole page.
    You need to query https://1270.0.1:8081/index.html
    I have never used ab before, so I do not know the options. Here as per your
    change:

    This is ApacheBench, Version 2.3 <$Revision: 655654 $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
    Licensed to The Apache Software Foundation, http://www.apache.org/

    Benchmarking alex (be patient)
    SSL read failed - closing connection
    3071383184:error:140943E8:SSL
    routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1195:SSL alert number 0
    SSL read failed - closing connection
    3071383184:error:140943E8:SSL
    routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1195:SSL alert number 0
    SSL read failed - closing connection
    3071383184:error:140943E8:SSL
    routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1195:SSL alert number 0
    ...
    SSL read failed - closing connection
    3071383184:error:140943E8:SSL
    routines:SSL3_READ_BYTES:reason(1000):s3_pkt.c:1195:SSL alert number 0
    Completed 1000 requests
    Finished 1000 requests


    Server Software:
    Server Hostname: alex
    Server Port: 8081
    SSL/TLS Protocol: TLSv1/SSLv3,ECDHE-RSA-AES256-SHA,1024,256

    Document Path: /index.html
    Document Length: 0 bytes

    Concurrency Level: 1000
    Time taken for tests: 37.563 seconds
    Complete requests: 1000
    Failed requests: 1000
    (Connect: 0, Receive: 0, Length: 1000, Exceptions: 0)
    Write errors: 0
    Non-2xx responses: 1000
    Total transferred: 142000 bytes
    HTML transferred: 19000 bytes
    Requests per second: 26.62 [#/sec] (mean)
    Time per request: 37562.759 [ms] (mean)
    Time per request: 37.563 [ms] (mean, across all concurrent requests)
    Transfer rate: 3.69 [Kbytes/sec] received

    Connection Times (ms)
    min mean[+/-sd] median max
    Connect: 17824 32741 3248.6 32868 37465
    Processing: 1 3529 3146.8 3242 18251
    Waiting: 1 3401 3024.7 3122 15953
    Total: 32983 36270 251.8 36240 37466

    Percentage of the requests served within a certain time (ms)
    50% 36240
    66% 36283
    75% 36384
    80% 36389
    90% 36393
    95% 36517
    98% 37064
    99% 37260
    100% 37466 (longest request)

    Linux performance is better no doubt.
    Perhaps.

    Alex
  • Patrick Mylund Nielsen at Sep 12, 2012 at 2:33 pm
    I used ab.
    Please try with weighttp:
    http://redmine.lighttpd.net/projects/weighttp/wiki which
    has the same syntax as ab. ab is a poor gauge since it uses a lot of
    resources (so benchmarking on the same box is sort of self-defeating), and
    it implements the HTTP protocol poorly.
    On Tue, Sep 11, 2012 at 3:02 AM, brainman wrote:
    On Monday, 10 September 2012 18:06:20 UTC+10, rahe...@gmail.com wrote:


    If you have ab.exe ...
    I used ab.

    # ab -n 10000 -c 1000 http://alex:8081/index.html

    This is ApacheBench, Version 2.3 <$Revision: 655654
    $>
    Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/

    Licensed to The Apache Software Foundation, http://www.apache.org/



    Benchmarking alex (be
    patient)
    Completed 1000
    requests
    Completed 2000
    requests
    Completed 3000
    requests
    Completed 4000
    requests
    Completed 5000
    requests
    Completed 6000
    requests
    Completed 7000
    requests
    Completed 8000
    requests
    Completed 9000
    requests
    Completed 10000
    requests
    Finished 10000
    requests




    Server
    Software:

    Server Hostname:
    alex
    Server Port:
    8081


    Document Path:
    /index.html
    Document Length: 0
    bytes


    Concurrency Level:
    1000
    Time taken for tests: 4.644
    seconds
    Complete requests:
    10000
    Failed requests:

    Write errors:

    Total transferred: 76811
    bytes
    HTML transferred: 0
    bytes
    Requests per second: 2153.31 [#/sec]
    (mean)
    Time per request: 464.401 [ms]
    (mean)
    Time per request: 0.464 [ms] (mean, across all concurrent
    requests)
    Transfer rate: 16.15 [Kbytes/sec]
    received


    Connection Times
    (ms)
    min mean[+/-sd] median
    max
    Connect: 143 203 65.5 201
    3125
    Processing: 165 224 27.1 225
    271
    Waiting: 5 94 53.5 93
    269
    Total: 320 427 61.1 432
    3332


    Percentage of the requests served within a certain time
    (ms)
    50%
    432
    66%
    433
    75%
    434
    80%
    434
    90%
    436
    95%
    437
    98%
    438
    99%
    438
    100% 3332 (longest
    request)

    Alex
    --
  • Agl at Sep 10, 2012 at 1:38 pm

    On Monday, September 10, 2012 3:33:40 AM UTC-4, rahe...@gmail.com wrote:
    I still see the CPU shooting very high with a continous F5 in Chrome.
    I will try your suggested methods as well.
    But is there any chance of improvement for this ?
    This test is running TLS handshakes in a fairly tight loop - it's expected
    to use a lot of CPU and isn't very representative of the real world.

    I believe that tweaking the ciphersuites will produce a good improvement if
    it's important to you.

    Optimising the P256 code for 32-bits is a lot of work, but I might get
    around to it at some point. Implementing SessionTickets is much less work,
    and may happen sooner.


    Cheers

    AGL
  • Raheelgup at Sep 10, 2012 at 3:14 pm
    Hi,

    Thanks for the input.
    I did a check on Linux and its performing better.
    Implementing SessionTickets is much less work, and may happen sooner.
    I am no expert with SSL and hence I dont know how can I do this.
    Could you point me to some docs / info to search on this ?

    Regards,
    R
    On Monday, September 10, 2012 7:08:14 PM UTC+5:30, agl wrote:
    On Monday, September 10, 2012 3:33:40 AM UTC-4, rahe...@gmail.com wrote:

    I still see the CPU shooting very high with a continous F5 in Chrome.
    I will try your suggested methods as well.
    But is there any chance of improvement for this ?
    This test is running TLS handshakes in a fairly tight loop - it's expected
    to use a lot of CPU and isn't very representative of the real world.

    I believe that tweaking the ciphersuites will produce a good improvement
    if it's important to you.

    Optimising the P256 code for 32-bits is a lot of work, but I might get
    around to it at some point. Implementing SessionTickets is much less work,
    and may happen sooner.


    Cheers

    AGL
  • Raheelgup at Sep 12, 2012 at 2:19 pm
    Hi,

    @agl, how should I implement the Session Tickets ?
    I am new at this and I am making some mission critical software which needs
    SSL certificates issued by Godaddy, Comodo etc. I dont know whether they
    will perform good. How should I optimise this ?

    Regards,
    R
    On Monday, September 10, 2012 7:08:14 PM UTC+5:30, agl wrote:
    On Monday, September 10, 2012 3:33:40 AM UTC-4, rahe...@gmail.com wrote:

    I still see the CPU shooting very high with a continous F5 in Chrome.
    I will try your suggested methods as well.
    But is there any chance of improvement for this ?
    This test is running TLS handshakes in a fairly tight loop - it's expected
    to use a lot of CPU and isn't very representative of the real world.

    I believe that tweaking the ciphersuites will produce a good improvement
    if it's important to you.

    Optimising the P256 code for 32-bits is a lot of work, but I might get
    around to it at some point. Implementing SessionTickets is much less work,
    and may happen sooner.


    Cheers

    AGL
    --
  • Adam Langley at Sep 12, 2012 at 5:17 pm

    On Wed, Sep 12, 2012 at 10:11 AM, wrote:
    @agl, how should I implement the Session Tickets ?
    I am new at this and I am making some mission critical software which needs
    SSL certificates issued by Godaddy, Comodo etc. I dont know whether they
    will perform good. How should I optimise this ?
    I'm afraid that if you're not familiar with TLS then I fear that
    implementing SessionTickets is probably not a viable plan. I do get
    scraps of time to work on Go now and then and I may be able to do it
    in the coming weeks.

    Several folks have apparently found crypto/tls's performance to be
    acceptable as is and you should know that your `F5 test' is pessimal:
    in the real word HTTPS connection are used for more than one request.

    Tweaking the CipherSuites to disable forward security as I suggested
    will net considerable gains if need be. But you should be aware that
    Go's crypto code has not been studied to the extent that libraries
    like OpenSSL have. Security practice suggests that you might want to
    have an OpenSSL based server front your HTTPS connections for that
    reason alone and that would also let benefit from OpenSSL's
    performance.


    Cheers

    AGL

    --
  • Raheelgup at Sep 12, 2012 at 3:14 pm
    Hi,
    I do get scraps of time to work on Go now and then and I may be able to
    do it in the coming weeks.

    I can wait for a month or two. Will it be possible to have it improved by
    then ? I dont mind using another go package if its better as well (but
    couldnt find one).
    in the real word HTTPS connection are used for more than one request.
    Agreed. Its working well on Linux. But since my app will be multi -
    platform, Windows should also work :) In Windows the pessimal F5 test fails
    with a Connection Reset error. That is what is concerning apart from the
    fact that CPU usage is very high.
    Security practice suggests that you might want to
    have an OpenSSL based server front your HTTPS connections for that
    reason alone and that would also let benefit from OpenSSL's
    performance.

    Are you suggesting running another web server in front of the application I
    write and then proxy it to the Go Application ?
    Or please elaborate. Your advise is very much appreciated :)
    On Wednesday, September 12, 2012 7:52:10 PM UTC+5:30, agl wrote:

    On Wed, Sep 12, 2012 at 10:11 AM, <rahe...@gmail.com <javascript:>>
    wrote:
    @agl, how should I implement the Session Tickets ?
    I am new at this and I am making some mission critical software which needs
    SSL certificates issued by Godaddy, Comodo etc. I dont know whether they
    will perform good. How should I optimise this ?
    I'm afraid that if you're not familiar with TLS then I fear that
    implementing SessionTickets is probably not a viable plan. I do get
    scraps of time to work on Go now and then and I may be able to do it
    in the coming weeks.

    Several folks have apparently found crypto/tls's performance to be
    acceptable as is and you should know that your `F5 test' is pessimal:
    in the real word HTTPS connection are used for more than one request.

    Tweaking the CipherSuites to disable forward security as I suggested
    will net considerable gains if need be. But you should be aware that
    Go's crypto code has not been studied to the extent that libraries
    like OpenSSL have. Security practice suggests that you might want to
    have an OpenSSL based server front your HTTPS connections for that
    reason alone and that would also let benefit from OpenSSL's
    performance.


    Cheers

    AGL
    --
  • Adam Langley at Sep 12, 2012 at 7:25 pm

    On Wed, Sep 12, 2012 at 11:06 AM, wrote:
    I can wait for a month or two. Will it be possible to have it improved by
    then ? I dont mind using another go package if its better as well (but
    couldnt find one).
    It seems likely that I can do it by then.
    Agreed. Its working well on Linux. But since my app will be multi -
    platform, Windows should also work :) In Windows the pessimal F5 test fails
    with a Connection Reset error. That is what is concerning apart from the
    fact that CPU usage is very high.
    The connection resets are concerning. I'm afraid that I don't have a
    Windows machine (perhaps I should setup a VM) but that's a bug
    somewhere. Is it possible to get pcap dump of that failing? That bug
    is independent of the fact that our ECDHE is slow.
    Are you suggesting running another web server in front of the application I
    write and then proxy it to the Go Application ?
    Yes, running something like nginx in front of Go means that you're
    running OpenSSL, which has been extensively reviewed, if nothing else.


    Cheers

    AGL

    --
  • Raheelgup at Sep 13, 2012 at 4:39 am
    It seems likely that I can do it by then.
    That will be great. If you do happen to make it, will it be possible to get
    the changed packages even before a new version of Golang is out ?
    Yes, running something like nginx in front of Go means that you're
    running OpenSSL, which has been extensively reviewed, if nothing else.

    I dont want to run nginx as its performance on Windows is REALLY BAD.
    If it were possible to have OpenSSL integrated into Golang, I would love to
    use that.

    At this point, I need to make a decision fast between QT (C++ Libs) and
    Golang as the language of choice for our new software.

    Golang and QT both perform equally well and its just the TLS holding me
    back. I just enjoyed Golang and made this software which runs perfect on
    the regular HTTP but HTTPS is very bad in performance and HTTPS is going to
    be the default we are going to offer because of security reasons.

    Golangs GC is also good and works and makes me worry less about memory.
    Its packaging mechanism is also superb.

    Regards,
    R
    On Thursday, September 13, 2012 12:25:00 AM UTC+5:30, agl wrote:

    On Wed, Sep 12, 2012 at 11:06 AM, <rahe...@gmail.com <javascript:>>
    wrote:
    I can wait for a month or two. Will it be possible to have it improved by
    then ? I dont mind using another go package if its better as well (but
    couldnt find one).
    It seems likely that I can do it by then.
    Agreed. Its working well on Linux. But since my app will be multi -
    platform, Windows should also work :) In Windows the pessimal F5 test fails
    with a Connection Reset error. That is what is concerning apart from the
    fact that CPU usage is very high.
    The connection resets are concerning. I'm afraid that I don't have a
    Windows machine (perhaps I should setup a VM) but that's a bug
    somewhere. Is it possible to get pcap dump of that failing? That bug
    is independent of the fact that our ECDHE is slow.
    Are you suggesting running another web server in front of the
    application I
    write and then proxy it to the Go Application ?
    Yes, running something like nginx in front of Go means that you're
    running OpenSSL, which has been extensively reviewed, if nothing else.


    Cheers

    AGL
    --
  • Brainman at Sep 13, 2012 at 12:44 am

    On Thursday, 13 September 2012 01:06:10 UTC+10, rahe...@gmail.com wrote:
    ... In Windows the pessimal F5 test fails with a Connection Reset error.
    That is what is concerning apart from the fact that CPU usage is very high.
    ...
    I can't reproduce the problem you are seeing, perhaps, you should be more
    precise. I use this program:

    package main

    import (
    "net/http"
    "os"
    "runtime/pprof"
    "time"
    )

    func main() {
    f, err := os.Create("profile")
    if err != nil {
    panic(err)
    }
    pprof.StartCPUProfile(f)
    go func() {
    time.Sleep(15 * time.Second)
    pprof.StopCPUProfile()
    println("profile written")
    f.Close()
    }()
    err = http.ListenAndServeTLS(":8081", "cert.pem", "key.pem", nil)
    if err != nil {
    panic(err)
    }
    }

    I compile it with latest version of go (from tip). I run it on windows/386
    and I use firefox browser to connect to it. I connect to
    https://localhost:8081/, get greeted with "security exception" screen, I
    get to "ignore" the security issue. I finally get "404 page not found"
    screen. I press F5, but nothing happens, I get same "404 page not found"
    screen.

    Perhaps, your experience is different. But you should be able to give us
    more clues about how to reproduce your problem. We need to understand what
    your problem is before we try fixing it.

    Also, please report your issue http://code.google.com/p/go/issues at
    standard place.

    Alex

    --
  • Raheelgup at Sep 13, 2012 at 4:29 am
    Hi,

    Try it on Chrome.
    Firefox seems to be a little slow in the F5 Test.
    Chrome sends as many as 3 times the number of requests.
    Firefox works because the number of requests is lesser.
    Is it possible to get pcap dump of that failing?
    What is this ?
    I will do it, if you point me how to do it sir.

    Regards,
    R
    On Thursday, September 13, 2012 6:14:07 AM UTC+5:30, brainman wrote:
    On Thursday, 13 September 2012 01:06:10 UTC+10, rahe...@gmail.com wrote:

    ... In Windows the pessimal F5 test fails with a Connection Reset error.
    That is what is concerning apart from the fact that CPU usage is very high.
    ...
    I can't reproduce the problem you are seeing, perhaps, you should be more
    precise. I use this program:

    package main

    import (
    "net/http"
    "os"
    "runtime/pprof"
    "time"
    )

    func main() {
    f, err := os.Create("profile")
    if err != nil {
    panic(err)
    }
    pprof.StartCPUProfile(f)
    go func() {
    time.Sleep(15 * time.Second)
    pprof.StopCPUProfile()
    println("profile written")
    f.Close()
    }()
    err = http.ListenAndServeTLS(":8081", "cert.pem", "key.pem", nil)
    if err != nil {
    panic(err)
    }
    }

    I compile it with latest version of go (from tip). I run it on windows/386
    and I use firefox browser to connect to it. I connect to
    https://localhost:8081/, get greeted with "security exception" screen, I
    get to "ignore" the security issue. I finally get "404 page not found"
    screen. I press F5, but nothing happens, I get same "404 page not found"
    screen.

    Perhaps, your experience is different. But you should be able to give us
    more clues about how to reproduce your problem. We need to understand what
    your problem is before we try fixing it.

    Also, please report your issue http://code.google.com/p/go/issues at
    standard place.

    Alex
    --
  • Brainman at Sep 13, 2012 at 4:42 am

    On Thursday, 13 September 2012 14:29:19 UTC+10, rahe...@gmail.com wrote:

    Try it on Chrome.
    Tried. Makes no difference.

    Alex

    --
  • Raheelgup at Sep 13, 2012 at 4:58 am
    Hi,

    For how long did you try. It happens in 2-3 minutes.
    BTW, my hardware specs : i5 2.66 GHz, 6 GB Ram, Win 7 64 Bit.
    I have attached a screenshot.
    On Thursday, September 13, 2012 10:12:38 AM UTC+5:30, brainman wrote:
    On Thursday, 13 September 2012 14:29:19 UTC+10, rahe...@gmail.com wrote:


    Try it on Chrome.
    Tried. Makes no difference.

    Alex
    --
  • Dave Cheney at Sep 13, 2012 at 4:47 am
    Dear OP,

    You need to develop a better benchmarking methodology here. Trying to benchmark a http server running on the same machine by refreshing your browser is not sufficient to eliminate many sources of latency and delay which are not part of the tls library.

    For example, the browser may be doing OCSP revocation checks as part of the tls handshake. This requires a round trip to an external sever.

    I think you should use a tool like siege or httpperf, running on a different machine, connected by a fast network to obtain statistically accurate benchmark results As has been previously discussed, ab is not useful here as it is inaccurate in HTTP mode an outright broken in HTTPS mode.

    Re: pcap, you should be able to download wireshark for your platform.
    On 13/ISPs09/2012, at 14:29, raheelgup@gmail.com wrote:

    Hi,

    Try it on Chrome.
    Firefox seems to be a little slow in the F5 Test.
    Chrome sends as many as 3 times the number of requests.
    Firefox works because the number of requests is lesser.
    Is it possible to get pcap dump of that failing?
    What is this ?
    I will do it, if you point me how to do it sir.

    Regards,
    R

    On Thursday, September 13, 2012 6:14:07 AM UTC+5:30, brainman wrote:
    On Thursday, 13 September 2012 01:06:10 UTC+10, rahe...@gmail.com wrote:
    ... In Windows the pessimal F5 test fails with a Connection Reset error. That is what is concerning apart from the fact that CPU usage is very high. ...


    I can't reproduce the problem you are seeing, perhaps, you should be more precise. I use this program:

    package main

    import (
    "net/http"
    "os"
    "runtime/pprof"
    "time"
    )

    func main() {
    f, err := os.Create("profile")
    if err != nil {
    panic(err)
    }
    pprof.StartCPUProfile(f)
    go func() {
    time.Sleep(15 * time.Second)
    pprof.StopCPUProfile()
    println("profile written")
    f.Close()
    }()
    err = http.ListenAndServeTLS(":8081", "cert.pem", "key.pem", nil)
    if err != nil {
    panic(err)
    }
    }

    I compile it with latest version of go (from tip). I run it on windows/386 and I use firefox browser to connect to it. I connect to https://localhost:8081/, get greeted with "security exception" screen, I get to "ignore" the security issue. I finally get "404 page not found" screen. I press F5, but nothing happens, I get same "404 page not found" screen.

    Perhaps, your experience is different. But you should be able to give us more clues about how to reproduce your problem. We need to understand what your problem is before we try fixing it.

    Also, please report your issue http://code.google.com/p/go/issues at standard place.

    Alex
    --
    --
  • Brainman at Sep 13, 2012 at 5:14 am

    On Thursday, 13 September 2012 14:47:25 UTC+10, Dave Cheney wrote:
    ...
    You need to develop a better benchmarking methodology here. ...
    My sentiment exactly.

    Re: pcap, you should be able to download wireshark for your platform.
    I tried to use WinPcap some time ago and could not see any 127.0.0.1
    interface traffic. Just a warning.

    Alex

    --
  • Raheelgup at Sep 13, 2012 at 11:42 am
    Hi,

    I have httperf and I wanted to know what command you want me to run ?

    On Thursday, September 13, 2012 10:44:38 AM UTC+5:30, brainman wrote:
    On Thursday, 13 September 2012 14:47:25 UTC+10, Dave Cheney wrote:

    ...
    You need to develop a better benchmarking methodology here. ...
    My sentiment exactly.

    Re: pcap, you should be able to download wireshark for your platform.
    I tried to use WinPcap some time ago and could not see any 127.0.0.1
    interface traffic. Just a warning.

    Alex
    --
  • James McKaskill at Sep 13, 2012 at 12:03 pm

    On Thu, Sep 13, 2012 at 1:14 AM, brainman wrote:
    On Thursday, 13 September 2012 14:47:25 UTC+10, Dave Cheney wrote:
    I tried to use WinPcap some time ago and could not see any 127.0.0.1
    interface traffic. Just a warning.
    Limitation of pcap on windows, but easy enough to get around.
    http://www.hsc.fr/ressources/articles/win_net_srv/missing_loopback.html

    -- James

    --

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedSep 8, '12 at 5:47p
activeSep 13, '12 at 12:03p
posts27
users8
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase