TOURNAMENT -- SHINE A LIGHT ON NF.

a few people have asked my why there was a large jump in Bandwidth. 

Tensmoor wrote: I'd like to echo both Rill & Lagavulin. I've learned a great deal during this tourney, not just about the game but also about IT. I've seen the enjoyment those taking part have had so far, the unstinting hard work put in by Kodabear and Digioso and most certainly not least, the raising of the awareness of NF.

I add my thanks to Rills.  With all of her comment +1 by me.

Most of the bugs have been described here in this thread I think.
They mostly had to do with things that I haven't thought about or some logical problems in the code. EG that reports have to be read chronologically and not by going through them player-per-player. Initial thought was: Download a api key for player A, then download his reports, then continue with player B. Now: Download all api keys, put all report IDs into a hash and run through that hash by sorting it chronologically.

Apart from these we had some other technical difficulties:
- The website performance. Building your database using 3rd normal form to avoid data redundancy is nice. Unless you have data in different tables and need to do lots of SQL joins to access it. We have three tables with report data. One for general report data like combat occurance, winner of the battle, coordinates and so on. One for armies with data like army name, owner of the army, alliance of the player. And then a third one for divisions with division names, commander names & health, troops and troop losses. So to get all data we had to do a join over three tables which took A LOT of time. The fix was to add relevant data (combat participants with alliance, troop numbers and losses) to the general report table. Problem solved. :)
- Unforseen issues related to the webhoster (cronjobs that can only run for max. 20min and then are aborted automatically by the webhoster), Suddenly all the Perl scripts didn't work anymore because the Perl installation was missing library files. And then suddently they were working again but the webhoster of course didn't do anything. And the problem right now with accessing the Illyriad-Servers. Koda is running the database updater on his own PC because his server suddently could not do that anymore. Most likely his webhoster is blocking this. Also the webhoster closes database connections after quite a short time when there was no activity (EG because the script was going through reports unrelated to the tournament). So had to make sure that connections are only opened when there is something to do. My own webhoster has a highter timeout here.
- Timezones. Sounds trivial, but isn't. The Illy servers are in a different time zone so you have to make sure that you get your timezones right. In Perl there are several ways to do this. One is very easy and that one is working on Kodas Server, my server and my PC. But not on Kodas PC. Both Koda and me use the same operating system on our PC so that's quite weird... Fix for Kodas PC: He changed his date/time settings to match the Illy servers.
- One thing we didn't know about the combat reports: The defenders report shows that the attacker used occupation as attack method but the defenders' report does not state the occupation time. You can only get this from the report of the attacker. So we had to make sure that the attackers' report is read as well to get that piece of information.
- Aborting downloads of reports/API keys. This was quite a hassle. I use the WWW::Mechanize Perl Modul to download all the stuff. Per default the module does a hard abort (die) and exits the whole script whenever it encounters an error. There are some options to avoid that which we are now using. But still we had to deal with corrupted downloaded files. So right now the script retries downloads whenever they fail. Sounds logical of course but in the initial versions I only thought about the best case. Meaning: No errors while downloading.
- One thing you might want to consider: Ctime or Unix Time is very nice for everything that has to do with times. You can easily sort though it, subtract and add easily and do all sorts of calculations. Know that a day has 86400 seconds! I'm always using Ctime because it makes things very easy. https://en.wikipedia.org/wiki/Unix_time
(Maybe not so) funny fact on this: Some of you might remember the big year 2000 problem which all IT companies thought to be the end of the world - and then almost nothing happened. Unix time is a 32bit variable that will 'full' in 2038. This time it may really be the end of the world. But rejoice, we have ~21,5 years left until we'll all die. Right now there is no solution that fixes it everywhere. :) https://en.wikipedia.org/wiki/Year_2038_problem
Note for me: Fix my website before 2038. :)
Oh, and if we survive 2038 - we'll all die in the year 10000 for sure because then we'll have the Y10k bug. But I don't care because I most likely will not be alive anymore at that time. Unless I find some thing that grants me eternal live.
Note: Need to find more sacrifices for my queen so that She may grand upon me eternal live.


Edited by Digioso - 12 Jun 2016 at 16:35

Monthly history

Jan 2016 Feb 2016 Mar 2016 Apr 2016 May 2016 Jun 2016 Jul 2016 Aug 2016 Sep 2016 Oct 2016 Nov 2016 Dec 2016   Month Unique visitors Number of visits Pages Hits Bandwidth Jan 2016 0 0 0 0 0 Feb 2016 0 0 0 0 0 Mar 2016 0 0 0 0 0 Apr 2016 10 42 226 507 8.45 MB May 2016 1,782 8,461 33,844 69,945 12.37 GB Jun 2016 1,558 8,602 30,673 60,173 6.14 GB Jul 2016 0 0 0 0 0 Aug 2016 0 0 0 0 0 Sep 2016 0 0 0 0 0 Oct 2016 0 0 0 0 0 Nov 2016 0 0 0 0 0 Dec 2016 0 0 0 0 0 Total 3,350 17,105 64,743 130,625 18.52 GB

   

Days of month

01 Jun 02 Jun 03 Jun 04 Jun 05 Jun 06 Jun 07 Jun 08 Jun 09 Jun 10 Jun 11 Jun 12 Jun 13 Jun 14 Jun 15 Jun 16 Jun 17 Jun 18 Jun 19 Jun 20 Jun 21 Jun 22 Jun 23 Jun 24 Jun 25 Jun 26 Jun 27 Jun 28 Jun 29 Jun 30 Jun   Average Day Number of visits Pages Hits Bandwidth 01 Jun 2016 522 1,929 3,676 1.88 GB 02 Jun 2016 463 1,942 3,531 417.80 MB 03 Jun 2016 465 1,809 3,509 207.20 MB 04 Jun 2016 487 1,644 3,127 205.66 MB 05 Jun 2016 517 1,994 3,955 244.39 MB 06 Jun 2016 530 1,806 3,462 226.45 MB 07 Jun 2016 524 1,847 3,798 241.14 MB 08 Jun 2016 505 1,873 3,854 250.45 MB 09 Jun 2016 515 1,905 3,845 259.30 MB 10 Jun 2016 449 1,609 3,208 246.89 MB 11 Jun 2016 447 1,477 3,023 209.31 MB 12 Jun 2016 485 1,816 3,740 273.98 MB 13 Jun 2016 527 2,103 4,259 361.31 MB 14 Jun 2016 480 1,569 3,197 273.45 MB 15 Jun 2016 478 1,592 2,860 246.71 MB 16 Jun 2016 444 1,515 2,890 233.96 MB 17 Jun 2016 473 1,531 3,100 284.34 MB 18 Jun 2016 222 561 895 129.23 MB 19 Jun 2016 69 151 244 46.76 MB 20 Jun 2016 0 0 0 0 21 Jun 2016 0 0 0 0 22 Jun 2016 0 0 0 0 23 Jun 2016 0 0 0 0 24 Jun 2016 0 0 0 0 25 Jun 2016 0 0 0 0 26 Jun 2016 0 0 0 0 27 Jun 2016 0 0 0 0 28 Jun 2016 0 0 0 0 29 Jun 2016 0 0 0 0 30 Jun 2016 0 0 0 0 Average 100 378 763 110.88 MB Total 8,602 30,673 60,173 6.14 GB

Edited by kodabear - 20 Jun 2016 at 03:51