On Tue, 13 Mar 2018, 15:31 ajs6f, <aj...@apache.org> wrote:

> 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


We defined a thrift interface which mimics the DG interface and this uses
thrift encoding. So there is no http in use. It's based on the existing
Jena thrift work...


>
> 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