On Thursday, September 15, 2011 11:35:24 AM UTC-4, Jonathan Lundell wrote: > > On Sep 15, 2011, at 8:04 AM, Ross Peoples wrote: > > > The way it is now, the JSON runs first, then the XML. I never interleaved > the two because I wanted to keep it simple. I can make the XML run first > instead and do another test: > > > > FINAL RESULTS > > ================================== > > JSON-RPC Average Time: 59.91 ms > > JSON-RPC Total Time Taken: 10007.80 ms > > XML-RPC Average Time: 21.84 ms > > XML-RPC Total Time Taken: 6201.04 ms > > Result: XML won by: 38.07 ms (274.3% faster) > > > > No change when I made XML run first, before JSON. > > Thanks for the summary, Ross. Comments below. > > > > > > > SUMMARY OF THREE ISSUES > > ======================== > > > > 1. Auth and JSON-RPC > > ------------------------------------- > > > > This problem stems from enabling Auth: > > > > auth = Auth(db) > > auth.define_tables() > > > > Whenever Auth is enabled, the average time per request for XML-RPC and > JSON-RPC are about 45 ms and 65 ms, respectively. However, whenever Auth is > not enabled, these times change dramatically, but only for XML-RPC. The > average time per request for XML-RPC and JSON-RPC is now about 20 ms and 60 > ms, respectively. The time it takes for JSON-RPC requests to run drops about > 5 ms per request, however, the time XML-RPC requests drops by 25 ms (more > than half). > > Am I correct that pretty much the same thing happens if you turn off the > define_tables call? > Yes, when I am 'disabling' auth, I am basically removing auth.define_tables() and auth = Auth(db)
> A side note: one table (signatures) gets defined in the Auth() call > regardless. I didn't see anything else in Auth.__init__ that could account > for much time. The HMAC key logic by default reads a file from the file > system, but presumably that's thoroughly cached by the OS. > > It's not so surprising that bypassing the Auth logic speeds things up a > bit, though 25ms seems a bit high for what it's doing. But I can't see any > explanation for a differential effect between JSON and XML. > > > > > 2. Unicode and JSON-RPC > > --------------------------------------- > > > > As for the unicode issue, I noticed this as well. I also tried going back > to simplejsonrpc, but that also returns strings as unicode. Are unicode > strings a requirement of the JSON-RPC protocol? > > I don't actually see a problem with this. In contrib.simplejsonrpc we > specify a charset of utf8 on the content-type header. Just for idle > curiosity you could try that and get rid of the charset specifier and see if > that's the trigger. But we actually want that. > I removed the utf8 part of the content-type and it still returns as unicode. I don't have a problem with unicode, as I think this what it should be doing. I am equally interested in why XML doesn't do this. > What I don't understand is why local strings like web2py_path are unicode > under JSON but not under XML. > > > > > > > 3. SSL and web2py's simplejsonrpc > > ---------------------------------------------------- > > > > Finally, on a note about web2py's simplejsonrpc implementation, it runs > much slower over SSL, possibly because it makes a new connection for each > request, whereas jsonrpclib and xmlrpclib leave the connection open for > subsequent requests. > > Yes, that's certainly what's going on. > > > The other big performance hit is that 2-3 places in web2py we do this: > > import contrib.simplejson as simplejson > > That really needs to change to something like this (with corresponding > changes to the code) > > try: > import json # try stdlib (py2.6) > except ImportError: > try: > import simplejson as json # try external module > except: > import gluon.contrib.simplejson as json # fall back on > pure-Python module > > The problem is that we need to be using the optimized C libraries when we > can (that's why XML is faster, I think). But the copy in contrib is pure > Python. It works, but it's slow. > I had a feeling this might have something to do with it. I wonder if preferring the pure Python libraries is adding to Problem #1.
