657579 - reduce MAX_MILLISECONDS_BETWEEN_RESULTS to <50ms

Status: RESOLVED INACTIVE

(Core :: SQLite and Embedded Database Bindings, defect)

Description

[Dietrich Ayala (:dietrich)]

https://mxr.mozilla.org/mozilla-central/source/storage/src/mozStorageAsyncStatementExecution.cpp#59

Per this project, we're aiming for 50ms response times: https://wiki.mozilla.org/Firefox/Features/50ms_ASSERT

Comment 1

[Andrew Sutherland [:asuth] (he/him)]

As a general awareness thing, and as I believe sdwilsh has mentioned previously, it's unlikely that the time factor is likely to have a meaningful impact, or the expected impact.

Specifically, queries that store results in an intermediary table (such as something using an ORDER BY that is not satisfied by the inherent ordering of the index/table) will tend to return their results all in one-go.

Queries that do not use an intermediary table will either go fast when data is available in cache, or require an I/O latency hit.  In the event of the I/O latency hit, the batch transmission will only occur after the I/O hit is taken, and in which case we would likely be able to include several more valid results operating out of cache.  (Specifically, the DB page loaded from disk, especially with a 16k page size, has a good chance of having more useful records on it that are effectively immediately available.)  Of course, it will vary be query.

Comment 2

[Shawn Wilsher :sdwilsh]

(In reply to comment #1)
> As a general awareness thing, and as I believe sdwilsh has mentioned
> previously, it's unlikely that the time factor is likely to have a
> meaningful impact, or the expected impact.
At least with the location bar, I think it might.  (see also: grumble grumble grumble)

> Specifically, queries that store results in an intermediary table (such as
> something using an ORDER BY that is not satisfied by the inherent ordering
> of the index/table) will tend to return their results all in one-go.
In the case of the location bar, we are very very good about not needing an intermediary table.

> Queries that do not use an intermediary table will either go fast when data
> is available in cache, or require an I/O latency hit.  In the event of the
> I/O latency hit, the batch transmission will only occur after the I/O hit is
> taken, and in which case we would likely be able to include several more
> valid results operating out of cache.  (Specifically, the DB page loaded
> from disk, especially with a 16k page size, has a good chance of having more
> useful records on it that are effectively immediately available.)  Of
> course, it will vary be query.
However, if you want results as fast as possible, getting a few really quick and then the next batch hits the numeric limit may not be so bad.

What would be interesting to know is how many dietrich was getting in the first batch with his testing.

Comment 3

[Andrew Sutherland [:asuth] (he/him)]

(In reply to comment #2)
> However, if you want results as fast as possible, getting a few really quick
> and then the next batch hits the numeric limit may not be so bad.

Yeah, that would be fine.  The problem case I just want to make sure everyone is aware of is this timeline:
- Get a few results out of cache, but less than the number-threshold.  Happens so quickly we don't cross the time threshold yet.
- Big I/O hit, blows the time threshold by a large factor
- Return previous results + 1 because of time threshold.
- Return a bunch of results hitting the number threshold.

Potential solutions for such a thing would be:
- Use a SQLite VFS that will tell us when it is asking the file-system for more blocks, use this to pre-emptively trigger a result flush.  (If we could find out if the file-system has the block in memory before flushing, that would be mo better.)
- Use a dead man timeout where another thread will flush our pending results if we don't flush the results ourselves first.  Obviously has horrible threading horribleness.
- Do the dead man timeout using a SQLite VFS so that mozStorage threading horribleness is reduced by being able to do the flushing on the same thread, at the cost of SQLite horribleness.  The current SQLite async VFS thinger doesn't really seem suitable.
 
> What would be interesting to know is how many dietrich was getting in the
> first batch with his testing.

Most interesting might be timeline events for each result returned and when we currently send the batch.  Assuming you know the SQL statement, you could aggregate a nice histogram without too much work.

Comment 4

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.