EVE Technology Lab

Thx Drax that may explain some of the setups we couldn't figure out. I'll make sure to add the information for people who want to setup crons.


In other news:

mmmmm fuelblocks

http://iceneko.com/eve/mmmfuelblocks.png

ohh nom nom nom.

Yeah I had planned on something like that, at least if you had perfect ME. Not sure if I'll have enough time to do more than that at first like different ME levels or allow you to calculate on the fly. But I hear you can get perfect ME right now for the FB BPOs before its release so not sure if that many people would care anyway. Not even sure why CCP even thought making people doing ME research on the fuel blocks was needed. Just seems dumb and pointless imo.

These are well known numbers. For 5% waste products, you divide the max usage by 10.5. For 10% waste products, you go with a 5.5% number. Take the largest number in a fuel block, 420 isotopes, and do the math so 420/10.5 = 40. ME 40 is a perfect build. If you want to just save all oxygen, ME 2 is fine. If you want to save all HW and LO3, 158/10.5 = ME 15 (rounded, CCP adds .5 and then truncates).

ME 15 is like a day and 4 hours. Also, Time Efficiency is totally worth it on these prints. With perfect skills and no build bonus, PL 0 is 4 minutes. With a good facility, at PL 3 you're looking at a build time of 2 minutes 6 seconds, PL 10 is 1:55, and PL 14 is 1:53. So I recommend you get at least a little Time Efficiency on there, another 6 hours maybe, and lots of empire slots.

Finally, blocks are finally able to be put in towers, but the API will still not return blocks because the API team didn't get the memo. Hopefully CCP will resolve this soon.

Then it's pretty simple: research an ME 40 BPO and he's said he'll add a fuel total in there. Done. No loss at all, easy math for our pos app, everyone wins. Just my opinion, but this is a pos fueling app, not a production application, don't make it too complicated.

If you want easy research, throw up a lab for a bit, or just research it in low sec as there are lots of open, very cheap slots.

Yeah, that was pretty 'goon like', giving you perfect ME numbers because addition is hard.

Well okay then lol. Well this kinda sucks in a sense because some of the patch notes could come out earlier but not anymore since they are all attached to the fuel blocks patch. Would be too many changes to reverse. Ohh well, expect the fuel block patch probably the week/weekend before January 24th. Gives me more time though so I'll probably add in some additional fixes or updates too. This may turn out to be one hell of a patch.

...or I'll wait till the 23rd...before working on it some more. bwhahaah :P

Well I had a reply and then the forums didn't actually post it so...yeah now I hate these new forums again.

Let's see if the forums eat this post.. (Seriously CCP, these are forums. There are hundreds of well written forums out there, how can you manage to have such horrible forums that previewing a post manages to destroy the post. Also, no [pre] or [code] tags? Seriously? :argh:)

I've been looking at optimizations for this app after I noticed that the track.php was taking a long time to load and that my database was screaming when it was loading. Poking into the query logs I found this query which seems to be called 2-3 times per tower:

SELECT *
FROM update_log
WHERE type_id = '52'
AND type = '1'
ORDER BY id DESC;

Ignoring the SELECT *, I ran an explain on this and noticed that there were no indexes (update_log_backup is just a duplicate of our update_log, I created it so I could play without killing existing data):

mysql> explain SELECT * FROM update_log_backup WHERE type_id = '52' AND type = '1' ORDER BY id DESC;
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-----------------------------+
| 1 | SIMPLE | update_log_backup | ALL | NULL | NULL | NULL | NULL | 454823 | Using where; Using filesort |
+----+-------------+-------------------+------+---------------+------+---------+------+--------+-----------------------------+

The query itself generates 2,799 rows and takes 0.23 and does so by doing a full table scan of almost 500k rows.

Time for indexes!

mysql> create index ULstuff on update_log_backup ( type, type_id );
Query OK, 0 rows affected (4.62 sec)
Records: 0 Duplicates: 0 Warnings: 0

mysql> explain SELECT * FROM update_log_backup WHERE type_id = '52' AND type = '1' ORDER BY id DESC;
+----+-------------+-------------------+------+---------------+---------+---------+-------------+------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-------------------+------+---------------+---------+---------+-------------+------+-----------------------------+
| 1 | SIMPLE | update_log_backup | ref | ULstuff | ULstuff | 12 | const,const | 2798 | Using where; Using filesort |
+----+-------------+-------------------+------+---------------+---------+---------+-------------+------+-----------------------------+

Hey, an index to read from, no more table scans! This reduced the query from 0.23 seconds to 0.01 seconds and returns the same number of rows. This took the load time of track.php from ~50 seconds to ~4 seconds.

It also looks like the function doing this query is only using the first row to determine the last update for a POS... If this is correct you may want to consider using a limit in there and only returning a single row instead of all of them..

Your query:

mysql> SELECT * FROM update_log_backup WHERE type_id = '52' AND type = '1' ORDER BY id DESC;
+--------+--------+---------+------+--------------------------------+------------+
| id | eve_id | type_id | type | action | datetime |
+--------+--------+---------+------+--------------------------------+------------+
| 454189 | 0 | 52 | 1 | EVEAPI XML STARBASE API UPDATE | 1323824523 |

With a limit:

mysql> SELECT * FROM update_log_backup WHERE type_id = '52' AND type = '1' ORDER BY id DESC limit 1;
+--------+--------+---------+------+--------------------------------+------------+
| id | eve_id | type_id | type | action | datetime |
+--------+--------+---------+------+--------------------------------+------------+
| 454189 | 0 | 52 | 1 | EVEAPI XML STARBASE API UPDATE | 1323824523 |
+--------+--------+---------+------+--------------------------------+------------+

Same data, 2,798 less rows.

You could also get the same result without looping over the list of POSes by doing a correlated sub-query or a self-join. In fact it should be possible to generate the entire from page from a single, wel optimized query (excluding pagination and other misc queries, I'm talking about just the table) with a few joins and possibly sub-selects.

I have other suggestions for optimizations after going through the code and the DB structure, but I'll hold off until I know if they'll be useful or not.. :)

Another quick thing:

In track.php at line 104 there is:

$row2 = $posmgmt->GetLastPosUpdate($row['pos_id']);

$row2 never seems to get called before the end of the function nor in the template. I commented this out and nothing seems to have broken and there is no reduced information on the tracking page as far as I can tell, but it is saving on some extra queries to the update_log table. :)

Or it was needed at one point, but something else changed, and never got removed. I'm guessing you can't find anyone that could explain 100% why every line was put in. Its been worked on by so many people now and changed with pos updates. If anyone wonders why I stopped working on it, it needs to be rewritten from scratch, but I didn't have the time. Fixing bugs became such a pain due to how complex it had gotten. Frozen is doing and excellent job at it though.