Performance of twisted web with HTTP/1.1 vs. HTTP/1.0
Hi folks, I'm using Quixote, and have recently started using Twisted instead of/in addition to Medusa to add SSL support to a web app. Ever since doing so, I've had the feeling that Twisted was slower than Medusa, but whenever I ran profiles of the app using ab (apache bench), the numbers indicated that twisted was comparable to medusa (a little slower, but only very slightly, and not enough that I should notice it 'seat of the pants', and not surprising considering it seems to be a more robust implementation). Today I noticed the problem again, (on a page that had lots of little icon type images) and decided that I *wasn't* going insane, it was definitely slower. Some more ab tests, and performance looked comparable to Medusa. Mind you, even though I'm adding Twisted because I want the SSL support, my tests are not using that SSL. In fact, at one stage, I even removed the code from my start script that enabled SSL to make sure that wasn't the problem. ab uses HTTP/1.0 to test an app, and of course most browsers use HTTP/1.1. I set up another, more sophisticated, test suite (ACT), where I could control the protocol, and ran the tests through it, and I confirmed that the protocol level was definitely the culprit. I ran the test using HTTP/1.0, and again using HTTP/1.1 (nothing else changed). Using HTTP/1.0, twisted served a small image about 131 times per second, but using HTTP/1.1 it dropped to about 5 requests per second. Yes, "Five." Has anyone else seen this type of behavior? Any ideas if it's something I may be doing wrong, or is this a known issue with Twisted? I'm running Twisted 1.2.0 (latest stable release) on Linux with Python 2.3.3 and have looked in the archives of twisted-web and twisted-users, and haven't seen anything about this. I'm not a member of this list, so if you have a reply, please cc me directly. Thanks, Jason Sibre
On Wed, Mar 17, 2004 at 11:02:54AM -0600, Jason Sibre wrote: [...]
ab uses HTTP/1.0 to test an app, and of course most browsers use HTTP/1.1. I set up another, more sophisticated, test suite (ACT), where I could control the protocol, and ran the tests through it, and I confirmed that the protocol level was definitely the culprit.
Where can I find this "ACT" test suite? My attempts to google for it have failed. I've run some quick & dodgy local tests with persistent connections and chunked encoding that found that no differences even close to 20x slower that you're seeing. I can't think of any other significant differences that HTTP/1.1 might trigger, though. Failing all else, a copy of the exact text of the request your test suite sends would be handy.
I'm not a member of this list, so if you have a reply, please cc me directly.
Done. -Andrew.
ACT is part of the Microsoft Visual Studio .NET. It stands for Application Center Test. The reason I tried it is that it allows the person setting up the test to control which headers are sent to the server. In fact, the test is actually controlled programmatically via VBScript (it hooks into Internet Explorer to 'record' the test, if you don't want to create it from scratch, which would be very tedious). If there's an open source tester that you'd rather I use for this discussion, please let me know about it, and I'll chase it down. In the meantime, I'm attaching the test script that is being used (test.vbs). It's written in VBScript, but it can't be run standalone, as the "Test" object won't exist unless it's being run from the ACT. It is easy to read however, so you can see what's going on. I've modified a portion of the script that ties Quixote to Twisted, so that I can 'peek' at the HTTP headers going into/coming out of Quixote. Here are the headers when things are running fast: INBOUND header GATEWAY_INTERFACE: CGI/1.1 INBOUND header HTTPS: off INBOUND header HTTP_ACCEPT: */* INBOUND header HTTP_ACCEPT_LANGUAGE: en-us INBOUND header HTTP_HOST: prototype.sibre.org:8081 INBOUND header HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) INBOUND header PATH_INFO: /static/htmlarea/images/ed_image.gif INBOUND header QUERY_STRING: INBOUND header REMOTE_ADDR: 192.168.1.253 INBOUND header REMOTE_HOST: 192.168.1.253 INBOUND header REMOTE_PORT: 1308 INBOUND header REQUEST_METHOD: GET INBOUND header REQUEST_URI: /static/htmlarea/images/ed_image.gif INBOUND header SCRIPT_FILENAME: INBOUND header SCRIPT_NAME: INBOUND header SERVER_NAME: prototype.sibre.org INBOUND header SERVER_PORT: 8081 INBOUND header SERVER_PROTOCOL: HTTP/1.0 INBOUND header SERVER_SOFTWARE: TwistedWeb/1.2.0 And here they are when things are running slow: INBOUND header GATEWAY_INTERFACE: CGI/1.1 INBOUND header HTTPS: off INBOUND header HTTP_ACCEPT: */* INBOUND header HTTP_ACCEPT_LANGUAGE: en-us INBOUND header HTTP_HOST: prototype.sibre.org:8081 INBOUND header HTTP_USER_AGENT: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322) INBOUND header PATH_INFO: /static/htmlarea/images/ed_image.gif INBOUND header QUERY_STRING: INBOUND header REMOTE_ADDR: 192.168.1.253 INBOUND header REMOTE_HOST: 192.168.1.253 INBOUND header REMOTE_PORT: 1445 INBOUND header REQUEST_METHOD: GET INBOUND header REQUEST_URI: /static/htmlarea/images/ed_image.gif INBOUND header SCRIPT_FILENAME: INBOUND header SCRIPT_NAME: INBOUND header SERVER_NAME: prototype.sibre.org INBOUND header SERVER_PORT: 8081 INBOUND header SERVER_PROTOCOL: HTTP/1.1 INBOUND header SERVER_SOFTWARE: TwistedWeb/1.2.0 I only note two differences, the HTTP/1.0 vs. HTTP/1.1 and the REMOTE_PORT 1308 vs. 1445, so, one significant difference. Not much help, I guess, but does it give you any clues? (I've joined the Twisted-web list for the duration of this conversation, at least) Thanks, Jason Sibre
-----Original Message----- From: Andrew Bennetts [mailto:andrew-twisted@puzzling.org] Sent: Monday, April 05, 2004 9:42 AM To: twisted-web@twistedmatrix.com Cc: jsibre@chironsys.com Subject: Re: [Twisted-web] Performance of twisted web with HTTP/1.1 vs. HTTP/1.0
On Wed, Mar 17, 2004 at 11:02:54AM -0600, Jason Sibre wrote: [...]
ab uses HTTP/1.0 to test an app, and of course most browsers
use HTTP/1.1.
I set up another, more sophisticated, test suite (ACT), where I could control the protocol, and ran the tests through it, and I confirmed that the protocol level was definitely the culprit.
Where can I find this "ACT" test suite? My attempts to google for it have failed.
I've run some quick & dodgy local tests with persistent connections and chunked encoding that found that no differences even close to 20x slower that you're seeing. I can't think of any other significant differences that HTTP/1.1 might trigger, though.
Failing all else, a copy of the exact text of the request your test suite sends would be handy.
I'm not a member of this list, so if you have a reply, please cc me directly.
Done.
-Andrew.
participants (3)
-
Andrew Bennetts -
Jason E. Sibre -
Jason Sibre