I'm finding that my background was too heavy and took quite a bit of processor power to render the artwork. I'm going to be drilling into the artwork and skins to reduce even more server loads. This is partial why I close the garage for the moment. I'm redoing it and reducing the picture loads and size so the photo can render faster. I'm so close to get the site fully accepted by Google but my biggest downfall is render time. Hence this why the grey background and no longer the tire print. 

 

I can play with colors, and other things to make the site nice looking but have to drop the heavy photos that are 2 MB to 6MB in size. These still need to be render and transmitted to the user. The lighter I can make the site the faster timing we will get. Kind of like going to the 1/4 mile track with your truck loaded with a cord of firewood. Dump the weight and re-run and see you gain time in your run. 

 

I've also got a nice app for Linux Terminal that will allow me to reconfigure all the exist apps into small formats without must loss. This is another step I've gotta do yet.

1 hour ago, Mopar1973Man said:

I'm finding that my background was too heavy and took quite a bit of processor power to render the artwork. I'm going to be drilling into the artwork and skins to reduce even more server loads. This is partial why I close the garage for the moment. I'm redoing it and reducing the picture loads and size so the photo can render faster. I'm so close to get the site fully accepted by Google but my biggest downfall is render time. Hence this why the grey background and no longer the tire print. 

 

I can play with colors, and other things to make the site nice looking but have to drop the heavy photos that are 2 MB to 6MB in size. These still need to be render and transmitted to the user. The lighter I can make the site the faster timing we will get. Kind of like going to the 1/4 mile track with your truck loaded with a cord of firewood. Dump the weight and re-run and see you gain time in your run. 

 

I've also got a nice app for Linux Terminal that will allow me to reconfigure all the exist apps into small formats without must loss. This is another step I've gotta do yet.

Is there a Quadzilla for this?  ;-) Thanks for all your hard work on this!!!

 

Lot of study work in watching numbers and server loads. We just took in like another 1,000 URLs that are now being indexed. There is about 2,000 been crawled but not indexed. I saw the drop in average placement which is a sign of new content coming into action. 

Edited December 15, 20204 yr by Mopar1973Man

Ok adding more features. Being our current search engine is rather weak in good responses I'm going to use a Google search engine and replace the current internal search. I know it double stacked for now but give me a bit of time ot build the skin up a bit more. 

 

 

I managed to shave off some server load with a bit a of tweaking of the disk cache settings. After several runs of bench testing and testing locally, across the network, and web based I managed to get the server load down enough to make a good score most of the time. 

 

As for the skin I'm going to start working on that with color, reduction of graphics, increase the use of icon fonts. Color is cheap, graphics are expensive server wise between the loading of the image and the pushing larger page load out to the members. Then consider that 80% of all the members come to the website with there cellphones. I need to make it super fast for mobile users and even quicker for the desktop members. The only way to do this is reduce the payload that has to be sent from the server. 

 

Like the old tire track background was heavy. I was roughly 1 MB in size. Then you try to make the server cache all this at the users end so they don't have to download every time switching to a new page. Now with the background image removed and just a color in the background it cheap. 

 

background-color: #edf0f4;

 

Yup that 1 MB background image replaced with a simple background color CSS command. The color is a 3 byte hexadecimal number. On a scale of 0 to 255 decimal how strong your RED, GREEN, BLUE...

 

ED (Hex) - 220 (Decimal) - RED 

F0 (Hex) - 240 (Decimal) - GREEN

F4 (Hex) - 244 (Decimal) - BLUE

 

Hence where the background color comes from code wise I know this is above most folks but just to show how deep and how far I've been taking this server performance, code work, and how serious I am to making the best website for Cummins owners. 

Haha... now I understand why the website looks like it’s been stuck in loading for a couple weeks, it was intentional. 
 

From the outside looking in, it looks incomplete and more like there is an issue now than with any slow loading before (I never noticed any).

 

Not trying to do anything other than provide an outside perspective. 

Several server side changes. Speed is improved from my bench testing from Texas and from here in Idaho and Canada. I've got the largest colorful paint by about 0.7 seconds page completes in about 2 seconds on average. I strip a bunch out of the theme with purpose of ditch the un-needed weight of pictures. Now slowly build it back up using better file formats I've been research picture compression and what formats are available on which browser (mobile and desktop).

 

Load testing I can server 1,000 people in batches of 100 in just under 8 seconds. 

 

Copied from my terminal after running ab (Apache Benchmark).

Concurrency Level:      100
Time taken for tests:   7.899 seconds
Complete requests:      1000
Failed requests:        0
Total transferred:      151734335 bytes
HTML transferred:       151096000 bytes
Requests per second:    126.60 [#/sec] (mean)
Time per request:       789.883 [ms] (mean)
Time per request:       7.899 [ms] (mean, across all concurrent requests)
Transfer rate:          18759.50 [Kbytes/sec] received

 

Copied from WHM (Apache Status currently)

 

Current Time: Thursday, 31-Dec-2020 17:13:22 MST
Restart Time: Thursday, 31-Dec-2020 05:52:57 MST
Parent Server Config. Generation: 1
Parent Server MPM Generation: 0
Server uptime: 11 hours 20 minutes 24 seconds
Server load: 0.13 0.28 0.28
Total accesses: 110629 - Total Traffic: 3.9 GB - Total Duration: 19234331
CPU Usage: u318.54 s82.93 cu199.33 cs49.59 - 1.59% CPU load
2.71 requests/sec - 100.2 kB/second - 37.0 kB/request - 173.863 ms/request
2 requests currently being processed, 173 idle workers

 

Since this server has 8 cores. I can server way more people. Server load numbers are percentage or that 8 cores so 8.00 would be 100% server load. I've managed to drop about 0.4 off the server load and made several changes to caching structure on the server as well in the software (Invision Power Board). I continue to benchmark test at random times and read the logs to tune out the errors.

 

Here is my current traffic amount as Google Analytics reporting for the last 180 days.

 

 

The graph above is how Google sees the site based on times and layout shift. The flip-flop occured when I set up the caching software the first time it was causing errors on the Apache server. After doing some reading and chasing found there is a code bug in the disk cache plugin for Apache and had to just wait for a release of the software update. Which I hope I got the update. Now got the cache fired back up and working but now need to watch to see if there is the same error issue. 

 

But comparing CF to M73M... M73M is still faster... 

As you can see I'm fighting the last little bit with the layout shift issues. Hence why the skin is incomplete looking right now so I can pour over the code and clean up that shift issue the best I can. 

Edited January 1, 20214 yr by Mopar1973Man