[BF4] Stats webpage for XpKiller's Stats Logger Plugin

[ImportBot]

Originally Posted by ty_ger07*:

 

Oh. Hmm. It's difficult with multiple hands in the same cookie jar.

 

Here is the last version of connect.php without that one added line:

https://github.com/tyger07/BF4-Serve...on/connect.php

[ImportBot]

Originally Posted by TMiland*:

 

Oh. Hmm. It's difficult with multiple hands in the same cookie jar.

 

Here is the last version of connect.php without that one added line:

https://github.com/tyger07/BF4-Serve...on/connect.php

So you cannot do it as default that way?

[ImportBot]

Originally Posted by ty_ger07*:

 

So you cannot do it as default that way?

Yeah, I can do what you want. I am just doing some errands.

[ImportBot]

Originally Posted by TMiland*:

 

Yeah, I can do what you want. I am just doing some errands.

Okay dude!

 

Maybe do some checks to see if it is "NULL" or "on" and display if either of them is set, and not display on off?

 

Not sure if all have that column?

[ImportBot]

Originally Posted by ty_ger07*:

 

So you cannot do it as default that way?

I synced an update to GitHub just now to allow it to work with adkats webadmin panel connection state changes.

 

The new update still won't filter out the "combined stats" for servers which aren't alive, but please let me know if this causes the dead servers to no longer be displayed.

 

Thank you!

 

Maybe do some checks to see if it is "NULL" or "on" and display if either of them is set, and not display on off?

Exactly.

"AND (`ConnectionState` IS NULL OR `ConnectionState` = 'on')"

[ImportBot]

Originally Posted by TMiland*:

 

I synced an update to GitHub just now to allow it to work with adkats webadmin panel connection state changes.

 

The new update still won't filter out the "combined stats" for servers which aren't alive, but please let me know if this causes the dead servers to no longer be displayed.

 

Thank you!

 

 

 

Exactly.

"AND (`ConnectionState` IS NULL OR `ConnectionState` = 'on')"

There we go! Nice! Thank you! :-)

[ImportBot]

Originally Posted by ty_ger07*:

 

There we go! Nice! Thank you! :-)

When I get all the combined stats queries updated to filter out the inactive server ids, hopefully that will create a decent performance increase by dropping from 300,000 soldiers down to 200,000 soldiers.

[ImportBot]

Originally Posted by TMiland*:

 

When I get all the combined stats queries updated to filter out the inactive server ids, hopefully that will create a decent performance increase by dropping from 300,000 soldiers down to 200,000 soldiers.

I don't mind the combined stats being displayed, that shows how many players we have had in the past, and i think thats nice.

 

BUT a performance increase is always welcome, so if we could compromise, display the total combined stats, but cache the disabled servers or something, idk.

[ImportBot]

Originally Posted by ty_ger07*:

 

Yea they weren't bots, the user I use for the stats pages is strictly set to select only. Those page view stats are completely wrong and from when I first setup the stats logging page.

 

Literally when I watched top on my VDS I could tell when someone was browsing the stats page because the MySQL process would pop to the top with 100% CPU usage and then fall back down when the page was done being generated.

Perhaps unfortunate in some ways, this stats code has slowly transformed from being lightweight, quick, and ugly into being full-featured, not lightweight, and slower. I am not sure what else I can do other than remove features.

[ImportBot]

Originally Posted by dyn*:

 

Just 2 days ago I was trying to locate a method to hide disabled servers and then y'all go and make it happen! Thank you ty and TM. Just made the stats page a little bit cleaner.

[ImportBot]

Originally Posted by TMiland*:

 

Perhaps unfortunate in some ways, this stats code has slowly transformed from being lightweight, quick, and ugly into being full-featured, not lightweight, and slower. I am not sure what else I can do other than remove features.

I say cache what you can of static content, i have no idea how/what you cache now, but i am sure you can analyze the speed and see what brings the speed and performance down. I have to say that i am impressed by how it looks now! Big improvements!

 

Just 2 days ago I was trying to locate a method to hide disabled servers and then y'all go and make it happen! Thank you ty and TM. Just made the stats page a little bit cleaner.

Yeah, it helped alot! Thank ty_ger07

[ImportBot]

Originally Posted by ty_ger07*:

 

You guys are all correct. I should create a temporary cache for some common items.

[ImportBot]

Originally Posted by TMiland*:

 

You guys are all correct. I should create a temporary cache for some common items.

Maybe this: http://www.phpfastcache.com/ ?

[ImportBot]

Originally Posted by ty_ger07*:

 

Maybe this: http://www.phpfastcache.com/ ?

Oh, I am not sure. Even though it is "safe", I am a little scared of cacheing the data to the server's memory or hard drive. It seems like a pretty big vulnerability if my code was hacked since it could theoretically cross over. (hack -> stats page -> disk -> mysite.com/cache/badfile -> delete all files on hard drive)

Even though my code is secure as far as I know, I would rather any security flaw be limited to the page or database and not extend to a file on the server's hard drive.

 

I was thinking of just saving common data to a table so the result could be fetched without recomputation as long as the result wasn't older than a certain time.

[ImportBot]

Originally Posted by ty_ger07*:

 

Hmm hmm hmm.

 

The vehicle stats are driving me nuts. Perhaps I should just drop the 'none' damage type completely and start over with the vehicle stats. It's such a pain that the new vehicle stats have the damage class and name/friendlyname SO screwed up.

[ImportBot]

Originally Posted by TMiland*:

 

Oh, I am not sure. Even though it is "safe", I am a little scared of cacheing the data to the server's memory or hard drive. It seems like a pretty big vulnerability if my code was hacked since it could theoretically cross over. (hack -> stats page -> disk -> mysite.com/cache/badfile -> delete all files on hard drive)

Even though my code is secure as far as I know, I would rather any security flaw be limited to the page or database and not extend to a file on the server's hard drive.

 

I was thinking of just saving common data to a table so the result could be fetched without recomputation as long as the result wasn't older than a certain time.

You are being paranoid!

 

I have full daily backups, so that's not an issue, and shouldn't be for anyone else either. Chances for getting hacked are small, and that script i linked are compatible with most of the caching software out there, and i see no risk of using them.

 

If you could make it compatible, people can decide what cache they want to use u know, all at their own risk.

[ImportBot]

Originally Posted by Prophet731*:

 

Only thing I see with the caching is that it probably wouldn't be very effective as the data from the database is always changing. There are very few spots where caching would help, even in my app.

[ImportBot]

Originally Posted by ty_ger07*:

 

Only thing I see with the caching is that it probably wouldn't be very effective as the data from the database is always changing. There are very few spots where caching would help, even in my app.

There seems to be only a tiny performance increase so far, but I am in the process of caching the total "combined servers" player count, the total chat rows, and player ranks in servers and in "combined servers".

 

Like you say, the database is very dynamic so caching will cause the accuracy of the data presented to be slightly decreased. And also, there are only certain things I can cache for only so long before I will totally screw up the accuracy of the information provided.

[ImportBot]

Originally Posted by Level*:

 

The Serbia flag is missing

 

RS noFlag.png

 

How can i add this ?

 

THX

 

-----

 

@edit

 

i found it ^^

 

Add in the common\constants.php

 

 

this -> 'Serbia'=>'RS'

[ImportBot]

Originally Posted by ty_ger07*:

 

The Serbia flag is missing

 

RS noFlag.png

 

How can i add this ?

 

THX

 

-----

 

@edit

 

i found it ^^

 

Add in the common\constants.php

 

 

this -> 'Serbia'=>'RS'

Thank you for the feedback. I will fix this in the next update.

[ImportBot]

Originally Posted by ty_ger07*:

 

Update released!

http://tyger07.github.io/BF4-Server-Stats/

 

Demo:

http://open-web-community.com/bf4sta...tats/index.php

 

Changes:

- Optimizations

- Caching

- Bug fixes

- Full vehicle stats

[ImportBot]

Originally Posted by ty_ger07*:

 

I see that VDV Buggy.png in /images/weapons needs to be renamed VDV_Buggy.png. Sorry about that.

[ImportBot]

Originally Posted by Prophet731*:

 

I love your commit message lol

 

Also, you should look into angularjs. You could probably clear out all the cluttered html in the PHP scripts and return json for single page app. Wouldn't be a bad improvement. I got lost trying to see if I can setup a angualrjs version of your app. I gave up after an hour.

[ImportBot]

Originally Posted by Level*:

 

Thank you for the feedback. I will fix this in the next update.

No problem I love your Stats page ^^

 

----

 

 

 

I have found something ^^

 

UCAV.png

[ImportBot]

Originally Posted by TMiland*:

 

Did some fiddling in the chat, consider adding Code:

AND `logMessage` NOT LIKE '!%'
		AND `logMessage` NOT LIKE '/%'

to the sql query, to filter out all the map votes /number and !commands

 

Feels a lot snappier after the last update!

[ImportBot]

Originally Posted by ty_ger07*:

 

Did some fiddling in the chat, consider adding Code:

AND `logMessage` NOT LIKE '!%'
		AND `logMessage` NOT LIKE '/%'

to the sql query, to filter out all the map votes /number and !commands

For some reason, in my testing, adding more constraints makes it get slightly slower.

 

In my testing,

 

This is faster:

Code:

$Messages_q = @mysqli_query($BF4stats,"
			SELECT `logDate`, `logSoldierName`, TRIM(`logMessage`) AS Message, `logSubset`
			FROM `tbl_chatlog`
			WHERE `ServerID` IN ({$valid_ids})
			ORDER BY {$rank} {$order}, `logDate` ASC
			LIMIT {$offset}, {$rowsperpage}
		");

Than this:

Code:

$Messages_q = @mysqli_query($BF4stats,"
			SELECT `logDate`, `logSoldierName`, TRIM(`logMessage`) AS Message, `logSubset`
			FROM `tbl_chatlog`
			WHERE `ServerID` IN ({$valid_ids})
			AND `logMessage` != ''
			AND `logMessage` NOT LIKE '%ID_CHAT_%'
			AND `logSoldierName` != 'Server'
			ORDER BY {$rank} {$order}, `logDate` ASC
			LIMIT {$offset}, {$rowsperpage}
		");

I am now confused which way to go. It seems like some of the filtering I already did is bad.

 

It seems like removing `logSubset` as an unnecessary additional column is a much more beneficial thing. The same holds true for the column `Rounds` in the leaderboard.

[ImportBot]

Originally Posted by Prophet731*:

 

For some reason, in my testing, adding more constraints makes it get slightly slower.

 

In my testing,

 

This is faster:

Code:

$Messages_q = @mysqli_query($BF4stats,"
            SELECT `logDate`, `logSoldierName`, TRIM(`logMessage`) AS Message, `logSubset`
            FROM `tbl_chatlog`
            WHERE `ServerID` IN ({$valid_ids})
            ORDER BY {$rank} {$order}, `logDate` ASC
            LIMIT {$offset}, {$rowsperpage}
        ");

Than this:

Code:

$Messages_q = @mysqli_query($BF4stats,"
            SELECT `logDate`, `logSoldierName`, TRIM(`logMessage`) AS Message, `logSubset`
            FROM `tbl_chatlog`
            WHERE `ServerID` IN ({$valid_ids})
            AND `logMessage` != ''
            AND `logMessage` NOT LIKE '%ID_CHAT_%'
            AND `logSoldierName` != 'Server'
            ORDER BY {$rank} {$order}, `logDate` ASC
            LIMIT {$offset}, {$rowsperpage}
        ");

I am now confused which way to go. It seems like some of the filtering I already did is bad.

 

It seems like removing `logSubset` as an unnecessary additional column is a much more beneficial thing. The same holds true for the column `Rounds` in the leaderboard.

The reason why the first query is faster than the second is all because of the `logMessage` column. Take out the `logMessage` and boom, faster query.

[ImportBot]

Originally Posted by ColColonCleaner*:

 

Also, why use the leading % with ID_CHAT? Don't those messages start with ID_CHAT?

 

ID_CHAT%

 

faster than

 

%ID_CHAT%

[ImportBot]

Originally Posted by ty_ger07*:

 

Also, why use the leading % with ID_CHAT? Don't those messages start with ID_CHAT?

 

ID_CHAT%

 

faster than

 

%ID_CHAT%

Understood.

[ImportBot]

Originally Posted by ty_ger07*:

 

The reason why the first query is faster than the second is all because of the `logMessage` column. Take out the `logMessage` and boom, faster query.

Umm...

 

The purpose of the chat log is to be able to see the chat messages. So, that isn't a very viable option, is it?