Fuseki can use a Thrift encoding via HTTP: 

https://jena.apache.org/documentation/io/rdf-binary.html

Andy is working on making it a bit easier to use:

https://issues.apache.org/jira/browse/JENA-1490

To your original question, Laura: are you absolutely sure that networking is 
the bottleneck in performance for your application? It's a _really_ good idea 
to do some profiling (even simple work like using the Posix 'time' utility with 
curl vs. using your application) to check that question before undertaking any 
specific optimization.

Keep in mind that on a bit-for-bit basis, HTTP with a good encoding like RDF 
Binary (Thrift) isn't _that_ much worse than any other network protocol. It is 
generally expensive to set up network connections, so if you want to optimize 
your network usage, using fewer connections/requests is going to buy you more 
performance more quickly than most other moves.


ajs6f

> On Mar 13, 2018, at 5:09 AM, Dick Murray <dandh...@gmail.com> wrote:
> 
> From an enterprise perspective http is well supported with years of
> development in associated stacks, such as load balancing etc. It also
> allows Devs to use different languages. That said we also employ Thrift
> based DGs which allow direct access from Python etc. It doesn't remove the
> overhead, it just replaces http with thrift, plus the dev needs to know the
> Jena API...
> 
> On Tue, 13 Mar 2018, 07:35 Laura Morales, <laure...@mail.com> wrote:
> 
>> I forgot to mention that I'm not looking at this from the perspective of a
>> user who wants to use a public endpoint. I'm looking at this from the
>> perspective of a developer making a website and using Jena/Fuseki as a
>> non-public backend database.
>> 
>> 
>> 
>> 
>> Sent: Tuesday, March 13, 2018 at 8:29 AM
>> From: "Laura Morales" <laure...@mail.com>
>> To: users@jena.apache.org
>> Cc: users@jena.apache.org
>> Subject: Re: client/server communication protocol
>> Am not saying one is better or worse than the other, I'm merely trying to
>> understand. If I understand correctly Fuseki is responsible for handling
>> connections, after then it passes my query to Jena which essentially will
>> parse my query and retrieve the data from a memory mapped file (TDB).
>> Since MySQL/Postgres use a custom binary protocol, I'm simply asking
>> myself if HTTP adds too much overhead and latency (and therefore is
>> significantly slower when dealing with a lot of requests) compared to a
>> custom protocol programmed on a lower level socket.
>> 
>> 
>> 
>> 
>> Sent: Tuesday, March 13, 2018 at 8:11 AM
>> From: "Lorenz Buehmann" <buehm...@informatik.uni-leipzig.de>
>> To: users@jena.apache.org
>> Subject: Re: client/server communication protocol
>> Well, Fuseki is exactly the HTTP layer on top of Jena. Without Fuseki,
>> which protocol do you want to use to communicate with Jena? The SPARQL
>> protocol [1] perfectly standardizes the communication via HTTP. Without
>> Fuseki, who should do the HTTP handling? Clearly, you could setup your
>> own Java server and do all the communication by yourself, e.g. using low
>> level sockets etc. - whether this makes sense, I don't know. I'd always
>> prefer standards, especially if you already have something like Fuseki
>> which does all the connection handling.
>> 
>> 
>> [1] https://www.w3.org/TR/sparql11-http-rdf-update/
>> 

Reply via email to