So what is the purpose of a pinging service? You go to the browser and access the website, that’s it. Right? What has pinging a website got to do with reducing the loading time?
One key factor that determines a website’s loading speed is the hosting plan and subscription. Some of my clients complain that their websites are sometimes taking forever to load. Upon further investigation, it turns out that the client is subscribed to a third party hosting service where the server is shared among several websites. It means that the server memory, disk space, and CPU cycles are shared by all sites running on the same server.
In such environments, all websites are competing for resources. A website that often gets site visits (e.g.: SiteA) in a given period are given priority and is cached in server memory. Thus a visitor request is served faster as the resources are already loaded in memory.
In this competing environment, a rarely visited site (e.g.: SiteB) gets pushed out of the cache memory. When a visitor tries to access SiteB, resources for SiteB would first be loaded in memory from the server hard disk. Only after everything is loaded will the site be able to serve the visitor request which, would take at minimum of 3 seconds and oftentimes up to 12 seconds or more, depending on the proximity of the server to the visitor’s location and the size of the page being served.
Any page loading delay beyond 3 seconds is considered too slow.
Loading time increase is directly proportional to the number of sites simultaneously hosted in the shared host server.
How does it impact the website owner. When a website is fairly new and the client is still in the process of marketing and ramping up site visits, it is most crucial that the website load really fast. It doesn’t help the marketing campaign when a prospective visitor navigates to the site and is greeted with a slow loading webpage.
The obvious solution for me is to recommend the upgrade to the client’s hosting service and opt for a private server. That means, the host server will be solely owned by the client’s website, no sharing of memory, disk, and CPU resources. But some clients are on a tight budget and would not, or could not afford to spend more on technical services that they look at as a necessary evil. Believe me, it sometimes is frustrating, but sometimes you I take it as a challenge and try to customize, and at the same time make my clients happy.
My workaround solution to this dilemma is based on the theory that if we can keep a constant flow of simulated site requests at uniform intervals per day, this will keep the host server happy and not unload the site resources in server memory, and thus eliminate the long loading times.
First, we need to create a polling service that can send site requests at a specified interval. But it requires a dedicated server that will be running uninterrupted 24/7 . You may use any low power, low memory computer that can host any of the popular operating systems for this. Just make sure it stays up and running all the time, and also it must have access to the internet.
There are several possible solutions to building a polling service. In my case, I implemented it using Ubuntu Linux bash script to send the actual request using wget, and systemd.
- wget is a command line executable used to download a webpage.
- systemd will turn our bash script into a daemon.
A daemon, is simply a long running process, that is never unloaded unless you power down or restart the machine. But once the machine is restarted it will automatically reload and run the polling service for you, so no problemo.
My implementation will be using Ubuntu 16.04 Linux OS, running on an old T1600 Xeon server. The T1600 is also used for several other software development projects I have going, like a jenkins/docker/vagrant build system for a micro services project, a mysql/pgsql db server, a java tomcat platform, a php apache server platform, a virtualbox server host, etc.. I will highlight each of these in future posts.
The following steps are all done using linux terminal bash commands, you may search google for the purpose and usage of each terminal commands as we go.
How to build the bash script:
- Create a directory where you want to keep all the necessary files for the ping service.
The first command will create a directory in the current path named your site-ping. You may use a different name.
The second command will change our path and bring us inside the your site-ping directory.
user?> mkdir yoursite-ping
user?> cd yoursite-ping
- Create a file named, yoursite-ping.sh. This will be our bash script that will execute the ping request to the website.
user?> touch yoursite-ping.sh - Edit file and add the following commands in the shell script. In this example I will use vim command line editor.
#!/usr/bin/env bash
for (( ; ;))
do
wget -q -O- http://www.yoursite.com > /dev/null
sleep 20m
done
What each line does:
The first line simply instructs the calling command that the following lines will be interpreted by the bash command.
The for do done directive, is a looping instruction. In this implementation we are creating an infinite loop, as described by the (( ; ; )) in the for line.
wget switches -q and -O- instructs wget to run quietly and send results /dev/null, respectively.
sleep after each loop, we want the request to pause for a given period. In this case we set the duration to 20 minutes. Set the period lower in case you don’t get good results.
- Save the file then make it executable. After saving and exiting from vim, chmod the script file.
user?> sudo chmod u+x yoursite-ping.sh- Copy file to a system path. In this case, I use /usr/local/sbin.
user?> cp yoursite-ping.sh /usr/local/sbin/ How to build the systemd daemon service:
- In the same directory, create a file named yoursite-ping.service
user?> touch yoursite-ping.service- Edit yoursite-ping.service using vim, add the following lines.
[Unit]
Description=yoursite.com Ping Service
After=network.target
[Service]
Restart=always
ExecStart=/usr/local/sbin/yoursite.com/yoursite-ping.sh
[Install]
WantedBy=multi-user.target
This is all we need to allow our ping service to load as a daemon and will restart on system reboot or a crash.
The After=network.target line, instructs systemd to load ping service only after the network service is loaded and connected to the internet.
- Save the changes in yoursite-ping.service, copy file to /etc/systemd/system/
user?> sudo cp yoursite-ping.service /etc/systemd/system/
This will allow systemd to pickup our service configuration on restart and locate our executable script.
- Instruct systemd to accept our service and start the service:
user?> sudo systemctl daemon-reload
user?> sudo systemctl start yoursite-ping.service
- Check daemon status. Use either of the 2 commands below:
user?> systemctl list-units --type=service --state=running | grep yoursite-ping
If the previous steps went with no hitch, the above command should show the line
yoursite-ping.service loaded active running yoursite.com Ping Service
or
user?> systemctl status yoursite-ping
Again, if everything went well in the previous steps. It will show the lines;
Loaded: loaded (/etc/systemd/system/yoursite-ping.service; enabled; vendor preset: enabled)
Active: active (running) since Tue 2015-04-24 15:36:33 UTC; xxh xxmin ago
You’re done! Send comments if you run into issues.
Although I wouldn’t recommend this solution as a permanent fix, it helps to have a way to resolve such issues and adapt as we go, especially on a very tight budget.
See my future posts on website optimization techniques.