Q-Raven,BobMarion,Chatserv,DjMaze,Hitwalker,Telli,64BitGuy

Hangin' Around Joined: Nov 03, 2004 Posts: 43

Well this question is for you experts and long time supporters of nuke!, I installed a hack to see just how many sql queries were being called each time a certain page loaded and right now from our main page it averages from 125 to 145 depending on the amount of users logged in..

Now I have seen the post over at nukecops.com by DjMaze and Steven about speeding up mainfile.php and their other speed tweaks and I applied these and they worked wonders!

Before we were making anywhere around 165 to 235 sql quires so it is apparent there must be many other ways to improve the speed and stress to the MySQL server and cpu usage that the standard package causes especially on high volume sites.

My question is DjMaze mentioned about the survey block reducing sql quires down to 3-4 quires from 23! WOW!

My question is I’m using nuke 7.3 patched and the standard block from that bundle how can I achieve this as well!

The next big question is for all you supporters and long time guru’s of the nuke community, Raven, Bob Marion, Chatserv, DjMaze, Hitwalker, Telli, Evader99, 64BitGuy and the many others that support the nuke community!

What things can I look for or change to even reduce more sql quires and speed up our site, I now about using less blocks that display total amounts of downloads web links or and reducing page size by using less of these things will also reduce this.

But how can we optimize the site for best performance. I see many nuke sites with only 35 or 45 total sql quires! Yet they run the same as us!

We currently have our site W3C 4.01 Strict Compliant and the hole site is google taped and we use cache lite and jpcache to optimize modules!

Your thoughts and opinions would be greatly appreciated!

Xtrax!

Posted: Fri Nov 11, 2005 2:42 pm

Well, I'd be amazed to see any site that is actually strict compliant. That would be a first given that there are over 30,000 HTML 4.01 Transitional Compliance bugs in Nuke. Strict compliance is even harder due to the nature of what some of the functions do presenation wise.

As for optimization, the biggest thing you can do is look for examples of queries being made for *

When you do that, you are in many cases (if not most) making queries that don't need to be made. I'm sure there are literally thousands of other ways to improve performance and frankly, it is something that I hope to get to later as it is a very important issue. I understand that "Quake" has been working on this with Technocrat in Nuke Evolution, and I suspect you'll see many of those improvement reaching other solutions soon as well including after-patched.

The best thing you can do is to eliminate wasteful blocks from your domain entirely. I wrote about this extensively and gave some examples when TechGFX was up.

Eliminating things that just suck resources (like scrolling marquee blocks, things like the games block which sucks about 400 sql queries, etc...) will really improve page load performance. The other thing is to wherever possible eliminate use of off-site images as your pages will only be as fast as those remote resources can be loaded.

While Cache_Lite is almost an imperitive (IMHO) these days to reduce some of the load from common blocks, you might also want to consider using mmcache instead of jpcache if you can. My experience with jpcache was mixed in terms of performance gains, but with mmcache I was amazed at the performance increase. This of course is not even a viable option for many due to the control requirements that you need on the server to run mmcache, but if you can use it (and configure it properly with the right amount of RAM allocations) it will make a huge difference. If you'd rather stick to a commercial solution, Zend's Memory Cache included with the deluxe optimizer is almost as good in terms of performance, but it is a paid solution.

Hope this helps.
Steph

Posted: Fri Nov 11, 2005 2:49 pm

Your are correct sorry about the mix up its not 4.01 strict according to W3C its HTML 4.01 Transitional, iso-8859-1, so sorry for my mis-type!

I will benchmark mmcache and see if their is any further improvements and I thank you for your advice Steph!

We are always thankful for any tips we can get!

I will be curious to see what other ways of improvement can be made as far as coding goes and what enhancements can be made.

Xtrax Smile

registered · Posted: Mon Nov 14, 2005 11:12 am

There are a ton of other code changes that can be made in nuke to speed it up. Quake has been creating a number of different ways to cache and speed up our package. Most of which will be released in the next Beta (Beta 3) which should be released this week or next week.