Hi, I have this problem all the time. Not on orientdb at present but its inevitable when the logic is far away from the data. So I'd say the problem is indeed your architecture. The logic should be on top of the db and its one of the benefits of java dbs. When running embedded it outperforms any server based architecture. So move your logic to the db server and have a courser grained interaction with the ui.
If you can not do that then you have to give up on the power of java (graph, vertex, edge) based interaction as that is by nature very fine grained with latency being a killer. Giving up means you'll have to construct sql queries to lift as much data as possible with as few as possible round trips. Its a pain and kills the joy of development for me so I'd say reconsider your architecture to have the webserver and db collocated. Cheers Pieter On 02/05/2016 16:46, Jean-Sebastien Lemay wrote: > So if I understand correctly, the reason it's slow is because there is > a back-and-forth communication between my code and the server at every > step of the way? I'm not sure if that's true, because my demo website > (with a lot less data) responds much faster, even though the network > latency should be the same (also hosted on AWS, database on separate > server, etc.) Why would my demo website, using the exact same code, > respond faster? > > Also, I couldn't find anything about Server Commands in the doc? Can > you give me a link? > > And as for the complexity of my operations, well that's inevitable, > that's why transactions are important. I'm building a social network > with a lot of features so I cannot further simplify my operations to > be honest. > > Best regards, > Jean > > > > > On Monday, May 2, 2016 at 8:25:30 PM UTC+8, l.garulli wrote: > > Hi Jean, > The reason is that in that piece of code you do a lot of operations: > > 1. lookup of vertex > 2. crossing edges > 3. loading all the edges, one per time > 4. crossing to the vertices > 5. loading connected vertices, one per time > > Over the network all these operation become expensive, because the > latency. > > So if you can't move the AppServer next to the database (but > remember you can still go in distributed even with plocal...), my > suggestion is to implement a Server side JS function that returns > what you need. > > Or you could create a Server Plugin or better, Server Commands > written in Java that talk with your app by using HTTP/JSON calls. > > > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB <http://orientdb.com/> > > > On 2 May 2016 at 13:26, Jean-Sebastien Lemay > <[email protected] <javascript:>> wrote: > > Hi Luca, the database isn't on the same server as the web > server, and will never be, so unfortunately I'm afraid I can't > use plocal mode. > > And Enrul, I guess indeed I will have to look at server-side > function. But that still implies a somewhat tedious re-write > of my application, since currently my logic is with my Java > code and I'm interacting with OrientVertex/OrientEdge object > and making multiple calls in separate modules (each module is > responsible for a specific type of entity for increased code > coherence). Now I'd have to rewrite the logic in Javascript > and reconsider my current architecture. > > I'm gonna have to rewrite whether it's server-side functions > or if I switch to a different database, though. I'm just > curious as to why it's taking so long to perform single-record > fetching based on a unique key, possibly the most fundamental > operation a database should be expected to perform quickly. > > Best regards, > Jean > > > On Monday, May 2, 2016 at 7:11:26 PM UTC+8, l.garulli wrote: > > Jean, > WDYT about connecting to OrientDB in plocal mode? > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB <http://orientdb.com/> > > > On 2 May 2016 at 12:14, Emrul Islam <[email protected]> wrote: > > Have you looked at using server-side functions: > > http://orientdb.com/docs/last/Functions.html > <http://orientdb.com/docs/last/Functions.html> > > you can write them in Java and they execute within the > OrientDb server. > > Also consider using hooks (even more performant) > : http://orientdb.com/docs/last/Java-Hooks.html > <http://orientdb.com/docs/last/Java-Hooks.html> > > > > On Monday, May 2, 2016 at 8:08:51 AM UTC+1, > Jean-Sebastien Lemay wrote: > > If client-side filtering is the issue, then I have > another problem. I'll need to rewrite my entire > back-end, and a lot of my operations have a lot of > conditions, which makes it almost impossible. > > For example, consider this operation: a user > connects to a channel. > 1) Register a new connection edge between user and > channel > 2) If number of connections between user and > channel jumped from 0 to 1, user is now part of > channel. If so, create an active user edge between > user and channel as well. > 3) If user became an active user and user is a > moderator of the channel, the channel is now > considered live (channel vertex update) > etc. > > A lot of 'IFs' which are better suited to Java > code than SQL code. > > What would you suggest for this situation? > > Best regards, > Jean > > > > On Monday, May 2, 2016 at 2:40:12 PM UTC+8, > l.garulli wrote: > > Are you using remote protocol, right? In this > case all your filtering is happening at client > side paying a lot in terms of latency. > > WDYT about executing a query/command that do > all your job at server side? > > Start with this query executed in > graph.command( new OCommandSQL("<query>") ); > > SELECT friendship.confirmed, inV( friendship ) > FROM > SELECT out('social').outE('friend') as > friendship FROM Account WHERE uuid = > 'blablablablablablablablabla' > ) > > > Best Regards, > > Luca Garulli > Founder & CEO > OrientDB <http://orientdb.com/> > > > On 30 April 2016 at 21:43, 'scott molinari' > via OrientDB <[email protected]> wrote: > > Ok. Sounds like you are right about the > profiles. I hope the ODB guys can help. I > think I pulled enough of the right > information out of you, so they can help. > Sorry, I am not more help. > > Scott > -- > > --- > 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 > <https://groups.google.com/d/optout>. > > > -- > > --- > 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 > <https://groups.google.com/d/optout>. > > > -- > > --- > 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] > <javascript:>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > > --- > 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] > <mailto:[email protected]>. > For more options, visit https://groups.google.com/d/optout. -- --- 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.
