Orient token-sharing best practices

Skip to first unread message

David Carr

Apr 19, 2015, 12:43:11 PM4/19/15
to orient-...@googlegroups.com
I have read the OrientDB documentation on network binary protocol tokens but it is unclear to what extent tokens can be shared in a typical web application. Imagine the following scenario:
  • One central OrientDB database configured with a global username/password pair for the web application.
  • 20 load-balanced web servers connect to the central OrientDB database.
  • Each of the 20 load-balanced web servers have 100 unique visitors (2,000 total sessions).
  • Each unique visitor session generates 20 pageviews (40,000 total pageviews).
  • Each (PHP) pageview connects to OrientDB (PhpOrient) using network binary protocol and runs one or more database queries (40,000 total OrientDB socket connections).
Question 1: Given this scenario, which token-sharing approach would be most performant for the overall system?
  1. Connect to OrientDB with username/password pair on every pageview. i.e. don't use tokens at all.
  2. Connect to OrientDB with username/password for each unique visitor, then store token to user session and reuse for each pageview (2,000 tokens)
  3. Make each web server connect to OrientDB with username/password ONCE, then reuse that token for all socket connections coming from that server (20 tokens).
  4. Make the overall system authenticate to OrientDB with username/password ONCE, and then share that same token across all the web servers (1 token).
Question 2: Under what circumstances does an OrientDB token expire?


May 18, 2015, 10:38:20 AM5/18/15
to orient-...@googlegroups.com
It depends on how you want manage user in your application:
if you are developing an application in a standard enterprise model where there is just one 'database user' you don't need to use the token, the reason for use it could be just to reduce the handshaking expecially with stateless client (like PHPOrient), and in this case you need just one token shared between webservers (your case 4).

if you want to have one 'database user' for each 'application user' is better have a token for each user so you can do profilng on each user (if you need to), so in this case you will have a token for each unique visitor(your case 2) the high number of token is not an issue because the token is not storead server side.

hope it help


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 orient-databa...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply all
Reply to author
0 new messages