Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Performance issues(?) #144

Open
RoySegall opened this issue Oct 12, 2016 · 2 comments
Open

Performance issues(?) #144

RoySegall opened this issue Oct 12, 2016 · 2 comments

Comments

@RoySegall
Copy link

RoySegall commented Oct 12, 2016

I'm working on setting up RethinkDB as a cache layer for Drupal and I saw that when I'm querying a MySQL server the response time is 0.7 seconds and when querying RethinkDB the process takes something like 1.4 seconds.

The request is for 1,000 records:

    for ($i = 0; $i <= 1000; $i++) {
      if ($operation == 'write') {
        $cache->set('testing' . $i, time());
      }
      else {
        $cache->get('testing' . $i, time());
      }
    }

Eventually, the query is:

    $documents = $this->table
      ->getMultiple($cids, ['index' => 'cid'])
      ->run($this->connection);

And as you can see I created an index for cid. which improve the query from 5 seconds to 1.4.

Profiling the query from RethinkDB side takes about 3ms so the suspect is the Driver.

Any idea?

@RoySegall
Copy link
Author

OK, I found out what's the problem. The first is used XDEBUG and it's slow the performance of PHP but It seems that createCursorFromResponse iterate over the results and create a cursor object.

This could very cool but it's not scaleable. Why not give to improve the DX by 2 ways:

  1. Change all the private methods to protected methods so developers could override the methods.
  2. Set a flag which can give the option to decide of cursor object need to be returned or just a normal array thus give the user much more fluid workflow.

@danielmewes thoughts?

@danielmewes
Copy link
Owner

@RoySegall if the full data set fits into memory, there are already two options for getting the result as an array rather than a cursor:

  1. Calling the ->toArray() method on the cursor object. This will convert the cursor into an array, but maintain the batched protocol between the client and the server. This has the advantage that less resources are used on the server, but at the cost of some additional communication and protocol overhead.
  2. (I think this is what you want): Appending a ->coerceTo("array") to the query, before the ->run. This will perform the array conversion server-side.

Can you try if option 2 gives you better performance? It will entirely cut out the cursor part.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants