Staggering SQL Stats For Nuke!

New Member Joined: May 06, 2004 Posts: 7

GeekyGuy wrote:

I'm not a coder, but I'll pledge my support for this. I'll toss in a couple of bucks now and then. I'll test code. I'll help write documentation.

I'm with Geekguy on this one. I'm not a coder, but I know enough about php to be able to spot problems in code and the like, but I also spent time as a tech writer, so I'm happy to chip in my assistance with this part.

Also, as a nukehelp.biz admin, I'm with Spottedhog on the offer. We are happy to provide forum and webspace to ease the load (if needed), and I am also happy to provide some of my own server space and bandwidth for a CVS repository or similar.

New Member Joined: Jun 29, 2004 Posts: 11 Location: USA

^^ What he said. Wink

Posted: Tue Oct 05, 2004 8:41 am

Actualy you can reduce the use drastical

With our CPG-Nuke CVS we have proven that after a heavily rewriting of php-nuke the database load is 6-50 database queries.
The resource usage dropped more then 50%
And security increased with more then 90%

You can do it if you want and CVS is a "must have" Wink

Client Joined: Oct 07, 2003 Posts: 735 Location: Ohio

This is directly connected to my max_question or max_resource error I get on my site. My host was rated as one of the top 5 as far as support and such but they limit the queries per hour to 50,000 on their MySQL databases. Why would Nuke use more than 50,000 queries in any given hour, unless it has some horrible overhead?

My options are to change host and loose my out of pocket expense of $95 of my hard earned money and go somewhere else.

Change to CPG Nuke and have all my hacks and custom modules stop working.

These are not viable options as far as I'm concerned.

Posted: Wed Nov 10, 2004 11:40 am

I think you are screwed unless you can keep things to less than 375 hits per hour.

Your homepage is generating a whopping 133 queries (divided by 50,000 = 375 page loads an hour).

I would instead start by dumping things that your really don't need. Like the 3D clock for example. I mean, if you look close, directly above that graphical clock, you already have a Digital clock with the date and time. So basically, you've got 2 clocks, when in actuality, you don't need either of them. Putting the date up in the header of your theme is fine, but tracking the time there needlessly sucks resources. The best place for the time to be (if anywhere) is in the login block.

I mean does anyone really need to know what time it is? Especially when their PC tells them this in the bottom right hand corner of their screen?

Next, your "Call of Duty Sites" uses non-existant0 icons... A big problem. Verify that these images exist locally and take about 10 seconds off your homepage load time, nevermind the errors that are getting generated everytime someone goes to any page that uses right column blocks because some of those images are non-existant. I would take a cold hard look at your Error_Log to see what else is going on.

Next, I noticed that you have that old seperate Hit counter. I'd dump that too and get a login block that has this function built in. When I compared using seperate to integrated on my site, I actually saved 4 queries... Don't ask me why. The same could be said for your "Top 10 Soldiers". Get a login block that has this information in it and you'll cut queries there too.

Finally, I noticed that you actually have 3 different menus on your site.
First, the "[3rd ID] Info"
Then, the "Combat Operations"
and Finally, "Menu"

I would suggest that you move all of this under the Main Menu block. As you can segment these functions any way you want (as you are already using custom menus) I really don't see the point of having seperate blocks to achieve this... again, if you are trying to save queries, un-needed blocks aren't helping you at all.

In closing, your site looked pretty good, but I would mention that eliminating right-click is pretty useless and is counter productive. Every quote you see here was accomplished with highlighting the text and going up to "Edit" / "Copy" in my browser window so you really haven't accomplished anything.

I would also consider enabling gzip to speed things up a tad.

As far as login blocks go?... Checkout http://phpnukies.org/ and look for NXP Blocks, you'll find that this is the new project that replaces all JAG blocks.

Hope this helps!

registered · Posted: Wed Nov 10, 2004 7:33 pm

Donovan wrote:

...My host was rated as one of the top 5 as far as support and such but they limit the queries per hour to 50,000 on their MySQL databases. Why would Nuke use more than 50,000 queries in any given hour, unless it has some horrible overhead?

Good question...

For the sake of conversation, and as a basis of comparison, I just checked my sql db runtime stats. The MySQL server has been running 9 days, 10 hours, 37 minutes and 26 seconds. LoL! Sorry if that's too much detail...

Anyway, the MySQL server had a total of 22,245,670 queries. That breaks down to an average of 98,161.19 queries an hour, for the last 9 days. So, if I was hosted where you are, I would be in serious trouble! Wink

Posted: Thu Dec 09, 2004 11:53 am

Creating an fork leads to more forking and improving as we noticed with CPG-Nuke.

You should start up with some ground rules as what is allowed to modify and what not.

To the CPG-Nuke Team there was so much lacking in PHP-Nuke that they actualy started with rewriting the base core to make it more sufficient, easy reading and better handling for customizations.
The query load dropped to 8-50 queries depending what you see.
The best login/security handling which they think is possible, and a lot more.

If you try to walk that same path you don't have an PHP-Nuke anymore, but your own CMS which maybe works with PHP-Nuke add-ons.

So think before you realy want to do something with the original code which will not be compatible with the next PHP-Nuke release.

CPG-Nuke doesn't look back to PHP-Nuke and with the new core they are even not trying to get PHP-Nuke add-ons to work by default but they need modifications to get it working.

If you have serious MySQL think about dedicated hosting or realy start raven his "port or not to port"

Posted: Mon Mar 27, 2006 8:28 am

<Bump>
I think this is an interesting and valuable topic - bumping to ensure it doesnt disappear too far away.