Quote from: PulsedMedia on June 23, 2011, 06:34:46 PM

Can this include some actual proxy kind of features, ie. caching?
So that this could be used behind a flaky internet connection to keep miners 100% at work, if the flakyness is in the seconds range?

A non-PHP getwork backend is planned to resolve this and other LP issues. PHP is not well-suited to this kind of task.

Quote from: PulsedMedia on June 24, 2011, 01:21:03 AM

Quote from: kjj on June 24, 2011, 01:10:22 AM

Check out the join that creates the status display.

LOL! Yeah that would cause some serious issues (first query in admin/index.php) 3rd query is a monstrosity.

Well there is the problem, using dynamic (on the fly created) tables etc.

These queries is almost like SELECT *, wonder if they ever hit any indexes ...

On my database, an EXPLAIN against that query shows zero table scans and very little processing. I spent a lot of time optimizing that query. Note that a few indexes that are required to prevent table scans are not present in the schema; these were added later and I don't have a database migration script just yet, so it's expected that these queries will run a bit slow unless you've manually created the needed indexes.

Quote from: PulsedMedia on June 24, 2011, 01:21:03 AM

Well there is the problem, using dynamic (on the fly created) tables etc.

This in particular made me lol. Subqueries can be an effective optimization technique if you know how to use them correctly, and any DBA knows that. In the "last 10 submissions" cases, MySQL creates a plan that executes the LIMIT after the JOIN, which results in a full table scan of work_data/submitted_work. Querying those tables in a subquery with LIMIT forces it to execute the limit first, which results in a very fast join. This was a pain point until I refactored the query to use a subquery to derive the data tables. Please know WTF you are talking about and use EXPLAIN, kthx.

Quote from: PulsedMedia on June 24, 2011, 12:13:50 PM

EDIT: I just checked, and interestingly doesn't hit index, which is really wierd. Oh well, i check why at better time.

Exactly. MySQL doesn't use the indexes in this case because it has decided to apply the LIMIT after the joins. So it does a table scan. And you don't need indexes to do a table scan, now do you? Essentially, MySQL's query analyzer sucks, and the subquery is the workaround.

So let's do some investigation:

Code:

mysql> SELECT COUNT(*) FROM work_data;
+----------+
| COUNT(*) |
+----------+
| 76422 |
+----------+
1 row in set (0.01 sec)

mysql> SELECT COUNT(*) FROM submitted_work;
+----------+
| COUNT(*) |
+----------+
| 126715 |
+----------+
1 row in set (0.00 sec)

After executing the dashboard status query:

Code:

3 rows in set (0.11 sec)

EXPLAIN on the dashboard status query:

Code:

Sorry, the query is fine. A bit big, but it's attempting to reduce quite a bit of data down to three rows. So meh. You do better and I'll take a patch.