There's going to be a lot of factors at play here that make it hard to test.
For example, if the server is far away, you'll have QoS prioritizing HTTP REST traffic. I've noticed that non HTTP traffic is generally treated with less priority. (The reason is quality.. A user can wait 1s for his FTP download or SSH command to return, but a consumer going to WallStreetJournal.com expects many fast HTTP response, and delays 'feel' slow.) This is just one factor. Also, long distance faulty connections, high network congestion (or unusually low congestion), or LFNs (long fat networks) might provide different results. How it's coded also matters. For the binary, are you recreating the DB connection on each query? Because that can impact things. On Monday, March 4, 2013 2:57:25 AM UTC-5, Tomas Bosak wrote: > > Hi Luca, > > I run these tests multiple times in batches of 20 from which I made > average numbers and the results were always around these figures, so I > don't think so it has to do something with flushing of the socket. > > On Monday, March 4, 2013 1:47:52 AM UTC+1, Lvc@ wrote: >> >> Hi Tomas, >> pretty weird! The second query in the remote case is 3 times slower. This >> could be due to an eccessive flushing of the socket? But in the second >> query is 4 times faster. Could you retry the same benchmark multiple times? >> >> Lvc@ >> >> >> >> On 3 March 2013 16:16, Tomas Bosak <[email protected]> wrote: >> >>> I found one bug in my connection pool, so after fix the numbers are like >>> this: >>> >>> Query: select from OGraphEdge limit 20 >>> >>> Average requests per seconds on local machine: >>> REST - 626 >>> Binary - 893 >>> >>> Average requests per seconds on remote machine: >>> REST - 66 >>> Binary - 21 >>> >>> Query: select from OGraphVertex limit 20 >>> >>> Average requests per seconds on local machine: >>> REST - 173 >>> Binary - 580 >>> >>> Average requests per seconds on remote machine: >>> REST - 31 >>> Binary - 122 >>> >>> Now the difference is more obvious however the speed of remote case with >>> the first query is still a mystery to me. Do you guys have similar tests >>> which you can share? >>> >>> On Saturday, March 2, 2013 10:35:12 AM UTC+1, Tomas Bosak wrote: >>>> >>>> I did some simple tests with C# based REST and binary drivers on the >>>> standard tinkerpop database which comes with graph edition and here are >>>> some numbers: >>>> >>>> Query: select from OGraphVertex limit 20 >>>> >>>> REST - 173 (average operations per second) >>>> Binary - 326 (average operations per second) >>>> >>>> Query: select from OGraphEdge limit 20 >>>> >>>> REST - 626 (average operations per second) >>>> Binary - 424 (average operations per second) >>>> >>>> It's strange to me that REST is around 200 operations per second faster >>>> in the second query that the binary driver, although the binary is close >>>> to >>>> being 2 times faster compared to the REST in the first query. >>>> >>>> On Tuesday, January 8, 2013 10:13:37 AM UTC+1, Tomas Bosak wrote: >>>>> >>>>> Hi folks, >>>>> >>>>> are there some benchmarks or any real numbers/evidence showing how >>>>> much performant is the binary protocol over the RESTful HTTP one apart >>>>> from >>>>> obvious deduction (like absence of HTTP headers when performing >>>>> operations or de/serialization performance)? >>>>> >>>> -- >>> >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "OrientDB" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> For more options, visit https://groups.google.com/groups/opt_out. >>> >>> >>> >> >> -- --- You received this message because you are subscribed to the Google Groups "OrientDB" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
