On Sep 15, 2011, at 10:49 AM, Ross Peoples wrote:
> That is correct. I removed Auth from the model, and just added one dummy
> table, and this table definition had the same effect of auth.define_tables().
> Then when I added "migrate=False" to my dummy table, the times for XML
> dropped back do
On Sep 15, 2011, at 11:31 AM, Ross Peoples wrote:
> Well, the jsonrpclib you had me download is that one that I was using for all
> of the testing, as it is certainly faster than the simplejsonrpc.py file. I
> also like the fact that it follows the xmlrpclib logic. I have found it to be
> more
I forgot to mention that I submitted a patch for preferring the C libraries
in web2py: http://code.google.com/p/web2py/issues/detail?id=426
Well, the jsonrpclib you had me download is that one that I was using for
all of the testing, as it is certainly faster than the simplejsonrpc.py
file. I also like the fact that it follows the xmlrpclib logic. I have found
it to be more consistent. I also like that it is mature. It is licensed
That is correct. I removed Auth from the model, and just added one dummy
table, and this table definition had the same effect of
auth.define_tables(). Then when I added "migrate=False" to my dummy table,
the times for XML dropped back down to 20 ms. During all of this, the JSON
times remained b
On Thursday, September 15, 2011 1:09:27 PM UTC-4, Ross Peoples wrote:
>
>
> So it looks like we've narrowed down the problem to migrations.
>
That sounds about right (it is usually suggested to turn off migrations in
order to improve speed), but the real puzzle is why turning off migrations
(or
On Sep 15, 2011, at 10:09 AM, Ross Peoples wrote:
> I think we can rule out the json serializer. I just replaced the code in
> tools.py and serializers.py and tried this. I also confirmed that the C json
> library was installed. There wasn't any change. However, I wonder if I should
> send thos
I think we can rule out the json serializer. I just replaced the code in
tools.py and serializers.py and tried this. I also confirmed that the C json
library was installed. There wasn't any change. However, I wonder if I
should send those changes to Massimo as a patch anyways since it seems like
On Sep 15, 2011, at 8:45 AM, Ross Peoples wrote:
> 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
On Sep 15, 2011, at 8:45 AM, Ross Peoples wrote:
> > 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
> >
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 an
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-RP
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
On Sep 15, 2011, at 7:01 AM, Jonathan Lundell wrote:
> On Sep 15, 2011, at 5:06 AM, Ross Peoples wrote:
>
>> Now, when I run the RPC services, this is what I get WITHOUT Auth (sorry, I
>> couldn't find a good way to format this):
>>
>
> Thanks, I can figure out something in an editor to look m
On Sep 15, 2011, at 5:06 AM, Ross Peoples wrote:
> Now, when I run the RPC services, this is what I get WITHOUT Auth (sorry, I
> couldn't find a good way to format this):
>
Thanks, I can figure out something in an editor to look more closely.
Something I don't understand. Massimo, do you? Anth
Ok, this is what I had to do in order to get the headers to work over RPC,
since it can't serialize file objects and things like that:
@service.xmlrpc
@service.jsonrpc
def headers():
"""
Returns the request headers.
@return: request headers as dict.
"""
h = dict(**request
On Sep 14, 2011, at 1:23 PM, Ross Peoples wrote:
> I don't think request stores headers. I tried but couldn't find it in the
> sources or through introspection. The response object has it, and I included
> that here. Had to do some work arounds as just returning response.headers
> generated a t
I don't think request stores headers. I tried but couldn't find it in the
sources or through introspection. The response object has it, and I included
that here. Had to do some work arounds as just returning response.headers
generated a ticket, but these are the headers for when Auth is activate
I'm away from my sources for a while. I think you'll find the headers in
request.headers. How about an rpc function that just returns them.
On Sep 14, 2011, at 12:13 PM, Ross Peoples wrote:
> I'll see if I can intercept the headers somehow. If you are interested in
> seeing if this happens in
On Sep 14, 2011, at 11:29 AM, Anthony wrote:
> On Wednesday, September 14, 2011 2:20:26 PM UTC-4, Jonathan Lundell wrote:
>>
>> How can the JSON times have increased (slightly) with the removal of all the
>> db.py code? This seems odd.
>>
>
> The JSON-vs-XML speed issue probably has to do with
On Wednesday, September 14, 2011 2:20:26 PM UTC-4, Jonathan Lundell wrote:
>
>
> How can the JSON times have increased (slightly) with the removal of all
> the db.py code? This seems odd.
>
>
> The JSON-vs-XML speed issue probably has to do with using the pure-Python
> simplejson library from con
On Sep 14, 2011, at 11:16 AM, Ross Peoples wrote:
> Normally, I wouldn't use that kind of percentage, except I wanted to
> highlight the large gap between the two protocols with Auth is used. JSON-RPC
> calls stay around 56 ms regardless of what I enable or disable in db.py. But
> for some reas
On Sep 14, 2011, at 11:07 AM, Anthony wrote:
> On Wednesday, September 14, 2011 1:25:37 PM UTC-4, Ross Peoples wrote:
> I also took Anthony's advice and removed all the models, except for three
> lines from db.py that are required:
>
> from gluon.tools import Service
> service = Service()
> resp
Normally, I wouldn't use that kind of percentage, except I wanted to
highlight the large gap between the two protocols with Auth is used.
JSON-RPC calls stay around 56 ms regardless of what I enable or disable in
db.py. But for some reason, XML-RPC falls from 45 ms to 18 ms when Auth is
disable
On Sep 14, 2011, at 10:47 AM, Ross Peoples wrote:
> Ok, I think I've narrowed down the problem:
>
> I put the old db.py file back (the one from the welcome app), then I
> commented everything. The percentage difference with everything commented out
> is XML 293% faster. I started uncommenting l
On Wednesday, September 14, 2011 1:25:37 PM UTC-4, Ross Peoples wrote:
>
> I also took Anthony's advice and removed all the models, except for three
> lines from db.py that are required:
>
> from gluon.tools import Service
> service = Service()
> response.generic_patterns = ['*']
>
> This has chan
Ok, I think I've narrowed down the problem:
I put the old db.py file back (the one from the welcome app), then I
commented everything. The percentage difference with everything commented
out is XML 293% faster. I started uncommenting lines, one by one and running
the test with each one. I enabl
On Sep 14, 2011, at 10:25 AM, Ross Peoples wrote:
> Jonathan,
>
> Good point about the nop. The nop is on BOTH protocols and does not count
> against the total time or the averages. Here are the results from that:
I'm still puzzled by the anomalous JSON ADD time. How about dropping a second
AD
Jonathan,
Good point about the nop. The nop is on BOTH protocols and does not count
against the total time or the averages. Here are the results from that:
ADD TWO NUMBERS
==
JSON-RPC: 75.57 ms
XML-RPC: 45.65 ms
Result: XML won by: 29.92 ms (165.5% faster)
CONCA
On Sep 14, 2011, at 8:41 AM, Ross Peoples wrote:
> I have downloaded the jsonrpclib and rerun the SSL without Sessions test
> again. MUCH better:
Good.
Another suggestion: insert some dummy request, a nop of some sort, as the first
operation (before ADD). I'm guessing that in both cases (JSON
Jonathan,
I remember now that sessions were optimized so that you didn't need to use
session.forget(response) to increase performance. I ran these tests several
times, and each test run makes 100 RPC calls per protocol, so there is a
large test sample size. When playing with sessions, I would c
Jonathan,
I have downloaded the jsonrpclib and rerun the SSL without Sessions test
again. MUCH better:
ADD TWO NUMBERS
==
JSON-RPC: 102.86 ms
XML-RPC: 62.83 ms
Result: XML won by: 40.04 ms
CONCATENATE TWO STRINGS
==
JSON-RPC: 47.3
On Sep 14, 2011, at 7:49 AM, Ross Peoples wrote:
> As you can see, there wasn't much of a change. In fact, turning off sessions
> added about 400 ms to the testing time. Now let's try with SSL:
>
Have you done enough runs to know what kind of noise level you're getting? I'd
be sort of surprise
On Sep 14, 2011, at 7:49 AM, Ross Peoples wrote:
> I ran this test several times because of the HUGE difference between the
> protocols when used over SSL. I think this may be more of a problem with the
> JSON client or server rather than the protocol itself. You'll see what I mean:
>
I believ
This is by no means an academic benchmark, but I was doing some testing with
RPC methods and decided to come up with a benchmark to get some average
times for the time it takes to make several types of RPC calls, and if one
protocol has a performance advantage over another. I tested JSON-RPC and
35 matches
Mail list logo
