-
Renegades working with Beaulieu to put on this show on 16th June 2024. Renegades meeting at Rownhams Services to leave at 8.00am to convoy down to Beaulieu.
https://www.solent-renegades.co.uk/threads/beaulieu-custom-and-american-show-16th-june-2024.55909/
Forum Speed
- Thread starter TransAmDan
- Start date
Just noticed that on my phone too. arggh, why has that changed. Its all the same as it was a couple of weeks ago. lol, I'm on the case.
Alternative chat box implemented now. It have more control, although we probably wont need t, but you can block people. The main thing is, that it doesn't stick out the edge of the screen like the other one started to do. 
an88fiero
Super Moderator
We are still having this problem
we are more and more on the forum at the same time in the evening now
Humm an interesting one. Sarah and i both on it at work today, all worked well. I'm not sure how to track that down unless I fire up that monitor program and see what the server is doing when you two are online.
in the meantime, I will get two computers and a phone on 3 different accounts at the same time.
in the meantime, I will get two computers and a phone on 3 different accounts at the same time.
An extra boost on forum speed has been unleashed.
PHP generation (the main webpage) served to your browsers and take a little while to generate, usually under half a second. One your browser receives this, it then needs to go and fetch any images and stylesheets to make the page look correct. Shorting these extra files on a Content Delivery Network (CDN) it speeds up our server and gets the files to the user quicker.
Optimising references to the CDN
The CDN is a content delivery network, which basically means its a caching server for the static items on the website. So things that don’t change often, like peoples avatar images, photo gallery images, lots of javasctipts, CSS files. All this can be served from server around the world which are geared up for delivering files and taking the load off our server, letting it serve the pages nice a fast. We have had the CDN for some time now, around 18 months.
Bascally any images that is on www.solent-renegades.co.uk, if the same URL was used, apart from CDN at the beginning, cdn.solent-renegades.co.uk it will serve that same image from the cache server. If the cache server doesn't have that file it fetched it from the website and remembers it for all future requests.
Images in forum posts
the link was done in class_bbcode, its in about 5 places. Changed from base path to cdn.solent-renegades.co.uk, also had to add to get the URL re-write to ignore attachment.php pages, as when the CDN request cam it it would redirect to an SEO page, still the right images, but then not cached.
Avatar images down the left hand side of a forum page changed to CDN by editing postbit_legacy template.
Xperience point banner bars are not in the usual place, but are in various PHP files I can eddit, the refer to the root of the forum for the URL so I can hard code cdn.solent-renegades.co.uk in its place.
Optimising PHP generation
The PHP is generated by Apache, but there is a plug in called nGinx, this can server the data quicker, do its been applied to the server to see how it goes. It certainly feels faster to me, but it could be my imagination, like when you add something to your car, it feels better. even if it is the same.
Overview
It seems the slow parts of the website now are served by google, which can't be helped, as we need the google ads to help with the running of the server. There is much more to be done to the website, checking all pages are pointing to the CDN, I have only done the main ones, like forum and gallery and parts of the Article section. Its great fun all this optimising. Once I get started I keep tinkering.
Its all working well, if anyone sees any issues please let me know.
PHP generation (the main webpage) served to your browsers and take a little while to generate, usually under half a second. One your browser receives this, it then needs to go and fetch any images and stylesheets to make the page look correct. Shorting these extra files on a Content Delivery Network (CDN) it speeds up our server and gets the files to the user quicker.
Optimising references to the CDN
The CDN is a content delivery network, which basically means its a caching server for the static items on the website. So things that don’t change often, like peoples avatar images, photo gallery images, lots of javasctipts, CSS files. All this can be served from server around the world which are geared up for delivering files and taking the load off our server, letting it serve the pages nice a fast. We have had the CDN for some time now, around 18 months.
Bascally any images that is on www.solent-renegades.co.uk, if the same URL was used, apart from CDN at the beginning, cdn.solent-renegades.co.uk it will serve that same image from the cache server. If the cache server doesn't have that file it fetched it from the website and remembers it for all future requests.
Images in forum posts
the link was done in class_bbcode, its in about 5 places. Changed from base path to cdn.solent-renegades.co.uk, also had to add to get the URL re-write to ignore attachment.php pages, as when the CDN request cam it it would redirect to an SEO page, still the right images, but then not cached.
Avatar images down the left hand side of a forum page changed to CDN by editing postbit_legacy template.
Xperience point banner bars are not in the usual place, but are in various PHP files I can eddit, the refer to the root of the forum for the URL so I can hard code cdn.solent-renegades.co.uk in its place.
Optimising PHP generation
The PHP is generated by Apache, but there is a plug in called nGinx, this can server the data quicker, do its been applied to the server to see how it goes. It certainly feels faster to me, but it could be my imagination, like when you add something to your car, it feels better.
even if it is the same. Overview
It seems the slow parts of the website now are served by google, which can't be helped, as we need the google ads to help with the running of the server. There is much more to be done to the website, checking all pages are pointing to the CDN, I have only done the main ones, like forum and gallery and parts of the Article section. Its great fun all this optimising. Once I get started I keep tinkering.
Its all working well, if anyone sees any issues please let me know.
Comparing website speed with a couple of days ago, so far not much improvement, as a lot of time was spent on getting it whizzy a few days back. The Dark green line is todays speed, the light green is from the 25th. This is a test of 8 web pages from our website, loaded many times, and simulating 50 users on line on the website. In the past during this time the website would get sluggish, however it wasn't even noticed.
This is showing total load time of the page, on average it was around 1.5seconds, which is pretty darn good.
Below its showing the time for the actual website to start to be return, this is a general performance figure of a website. This is around 170mS. I can't see this being improved much. Maybe it can....
This is showing total load time of the page, on average it was around 1.5seconds, which is pretty darn good.
Below its showing the time for the actual website to start to be return, this is a general performance figure of a website. This is around 170mS. I can't see this being improved much. Maybe it can....
More info on improving Web Server Performance with nginx (Linux) just incase you all wondered what it was
You can improve the work of the web server which hosts customer websites by installing nginx, a supplementary high-performance web server which is typically used as a reverse proxy server. This web server was specifically designed for delivering large amounts of static content (like images, video, css, xml, and so on). As opposed to Apache, nginx is much more efficient when it comes to a large number of concurrent connections. Another advantage of this web server comparing with Apache is that nginx has significantly lower memory footprint per client connection.
To leverage all benefits of nginx, Panel configures it as a reverse proxy server that stands between the Internet and Apache (see the diagram below). This means that nginx becomes a frontend web server that processes all incoming requests from site visitors. The requests are sent to Apache which, in turn, distinguishes requests for static and dynamic content. If a request is for a static file (like jpg, css, html, and so on), Apache passes the request through all registered handlers (applies .htaccess directory-level configuration, rewrites a URL, and so on) and returns to nginx a response which contains only a location of the requested file on the file system. nginx locates the file and sends it to the client. If the request is for a dynamic file (like a PHP script), Apache executes the file and sends the response to nginx, which delivers it to the client.
Such combination of nginx and Apache gives the following advantages:
Well all seems to be working well, apart from the hiccup this morning. It does seems to feel faster.
You can improve the work of the web server which hosts customer websites by installing nginx, a supplementary high-performance web server which is typically used as a reverse proxy server. This web server was specifically designed for delivering large amounts of static content (like images, video, css, xml, and so on). As opposed to Apache, nginx is much more efficient when it comes to a large number of concurrent connections. Another advantage of this web server comparing with Apache is that nginx has significantly lower memory footprint per client connection.
To leverage all benefits of nginx, Panel configures it as a reverse proxy server that stands between the Internet and Apache (see the diagram below). This means that nginx becomes a frontend web server that processes all incoming requests from site visitors. The requests are sent to Apache which, in turn, distinguishes requests for static and dynamic content. If a request is for a static file (like jpg, css, html, and so on), Apache passes the request through all registered handlers (applies .htaccess directory-level configuration, rewrites a URL, and so on) and returns to nginx a response which contains only a location of the requested file on the file system. nginx locates the file and sends it to the client. If the request is for a dynamic file (like a PHP script), Apache executes the file and sends the response to nginx, which delivers it to the client.
Such combination of nginx and Apache gives the following advantages:
- The maximum number of concurrent connections to a website increases.
- The consumption of server CPU and memory resources decreases.
The maximum effect will be achieved for websites with large amount of static content (like photo galleries, video streaming sites, and so on). - Efficiency of serving visitors with slow connection speed (GPRS, EDGE, 3G, and so on) improves.
For example, a client with the 10 KB/s connection requests some PHP script, which generates a 100 KB response. If there is no nginx on the server, the response is delivered by Apache. During these 10 seconds required to deliver the response, Apache and PHP continue to consume full system resources for this open connection. If nginx is installed, Apache forwards the response to nginx (the nginx-to-Apache connection is very fast as both of them are located on the same server) and releases system resources. As nginx has lower memory footprint, the overall load on the system decreases. If you have a large number of such slow connections, using of nginx will significantly improve website performance.
Well all seems to be working well, apart from the hiccup this morning. It does seems to feel faster.
Glad to hear it splendid.
splendid.
Had a bit of an issue around 4pm. It was an odd one, as the symptoms at first looked like it was the webserber, so restarted the HTTPD service and a few others, still doing the same. It seemed like the contend wasn't being served by the CDN, but it fetched this from the server. So logged into the CDN to prove things, and it did then appear to be the CDN, with many servers dotted around the world, if one is slow it sends content from another. So it is quite fail safe. However due to the server in London having issues it stopped us getting content from the Amsterdam one.
So basically in 2 years of the CDN its the first time anything like this has happened. They were quick to re-route the traffic so we were running again before 5pm.
Lets hope it doesn't happen again. Will keep an eye on that one.
So basically in 2 years of the CDN its the first time anything like this has happened. They were quick to re-route the traffic so we were running again before 5pm.
Lets hope it doesn't happen again. Will keep an eye on that one.
AmericanThunder
Super Moderator
:noidea: I don't do web stuff!!
Best way to be. lol.
Basically a major component in the line of getting data from the website to your computer went 'Ga Ga' for a while. :tsk:
Basically a major component in the line of getting data from the website to your computer went 'Ga Ga' for a while. :tsk:
The memory upgrade went well. Upgraded from 4gb up to 8gb. Although there was 1gb of ram free before, I could see drive accessing happening from time to time. So by putting in the extra ram its now using around 5gb of ram, so it was certainly the right way to go. Linix has a good way of working, that commonly used files are stored in RAM, if your applications start needing the RAM it is released.
So basically another speed increase, and it does seem to be working. I have been monitoring the accessing to the database, and will check stats on it tommorow, as it really takes about 24 hours of logs to get a good reading.
Also run it though a 50 user load test, it held up with no hiccups, and the processor activity remained low.
So basically another speed increase, and it does seem to be working. I have been monitoring the accessing to the database, and will check stats on it tommorow, as it really takes about 24 hours of logs to get a good reading.
Also run it though a 50 user load test, it held up with no hiccups, and the processor activity remained low.
Since having minor issues with slowness on larger images in the CDN(content delivery network), I removed pictures in the gallery being served by CDN, this was about the start of Nov 2014. I got the web server people 'eUKHost' to look into it, as MaxCDN the CDN people said that it was a DNS issues, after bouncing between the two companies, there was no resolution. All smaller images worked really face along with all the other include files that make up the web page. So as a result it was serving pretty fast direct form the web server, so we served the photo gallery image direct from the web server instead.
The way it should work, you ask for the image from the CDN, if it doesn't have it, it gets it from the web server and sends it on to you. after 3 requests for the same image it will be stored in cache, delivery much faster than a web server can do. Now fetching an images may take 0.5seconds, it takes around 1 second of the CDN doesn't have it, or 0.2 seconds if it does. Items will be stored in the CDN cache for 1 month. So even if this image isn't called for 3 weeks its ready to be sent.
How it was working is it could take 20 seconds to get it from the CDN if it wasn't cached, so this could have been many things, MaxCDN, or the web server not letting the CDN have it, or the network between the two servers.
Anyway, today, it looks like the CDN on larger images is working fine again. Yay
Also Sarah uploaded all the photos from Santa Pod FIA European Finals, usually uploaded in bunched of 80 at a time as it really slows down doing the last few, well last night an attempt of uploading 150photos at the same time the backup just started. The Webserver coped very well, obviously a lot of hard drive activity due to the back up. The uploading of photos did slow down but not as muct as before. So the memory upgraded was well worth while. Perhaps try to upload 200 next time in one go
The way it should work, you ask for the image from the CDN, if it doesn't have it, it gets it from the web server and sends it on to you. after 3 requests for the same image it will be stored in cache, delivery much faster than a web server can do. Now fetching an images may take 0.5seconds, it takes around 1 second of the CDN doesn't have it, or 0.2 seconds if it does. Items will be stored in the CDN cache for 1 month. So even if this image isn't called for 3 weeks its ready to be sent.
How it was working is it could take 20 seconds to get it from the CDN if it wasn't cached, so this could have been many things, MaxCDN, or the web server not letting the CDN have it, or the network between the two servers.
Anyway, today, it looks like the CDN on larger images is working fine again. Yay
Also Sarah uploaded all the photos from Santa Pod FIA European Finals, usually uploaded in bunched of 80 at a time as it really slows down doing the last few, well last night an attempt of uploading 150photos at the same time the backup just started. The Webserver coped very well, obviously a lot of hard drive activity due to the back up. The uploading of photos did slow down but not as muct as before. So the memory upgraded was well worth while. Perhaps try to upload 200 next time in one go
Last night seem to show signs of slowing down. Between 30% and 107% cpu usage, over 100% may seem odd but we can go to 800% usually the website is under 10% the pages seem sluggish to load.no have cleared cache which usually helps, but it's something deeper. Took me 5mins to get to this page to write this but I am on a mobile network and at the gym. Will take a look this afternoon, hdd accesses seem normal. Perhaps cdn an issue again and I can't log into their site. Which indicates they have problems.
Trying out something new. Using a network called CloudFlare, as well as MaxCDN, they are similar but now all our traffic goes via CloudFlare's servers, well controlled via their DNS.
I used to have an issue at work where it took a while for the website to load, it was like it took a while to find the DNs records, nothing concrete, but it was certainly slow.
Now it does appear to be loading the pages much faster than before.
The other nice things, is if the web server dies for a short period, apparently an older version of that page will be served by CloudFlare servers. I may have to try that later to see what happens.
Anyway all appears to be working well, the integration was done yesterday lunch time, and take a while for things to update, no down time. Looking good so far
I used to have an issue at work where it took a while for the website to load, it was like it took a while to find the DNs records, nothing concrete, but it was certainly slow.
Now it does appear to be loading the pages much faster than before.
The other nice things, is if the web server dies for a short period, apparently an older version of that page will be served by CloudFlare servers. I may have to try that later to see what happens.
Anyway all appears to be working well, the integration was done yesterday lunch time, and take a while for things to update, no down time. Looking good so far
Will be back on the case of forum speed tonight. It seems the recent CSS fix for the icons in the reply window has had a knock on effect of starting to slow down the website for some people.
I'll take a look when I get in
I'll take a look when I get in
Similar threads
