Forum Moderators: martinibuster
Logic says that faster loading pages give users and bots a better experience, but did anyone see an earnings boost after upgrading? Are visitors more likely to click ads on faster loading sites?
Or is the money better spent on code cleaning and content?
I am already on a dedicated server, millions of page impressions per month, and pages load at about average speed now, nothing to complain about, just wondering..
The new dedicated server hosts few more websites from our business which gets higher ranking and traffic from UK since last 4 years, since my site which has nothing to do with my business subject, now switched to neighboring IP address, i believe Google has started giving higher priorities to its search results in to UK with correlation to other sites on the server, resulting declining US traffic resulting low eCPM and now I am half at my daily earning. Hope this helps to others.
If you're on your own server now, I'd check the load at various times during the day (preferably during high-peak hours). I want to keep mine below 0.5 (this is on a linux machine btw). That means an average request from the server will take half a second. That's just any old request from the server, an already running process such as httpd may respond much quicker. It's hard to explain, but you want to keep this number low if possible.
The first thing I would personally do, is start to optimize your code. This can have as big or bigger effect on performance than upgrading your server. I was using ssi includes a lot that would call a cgi or a php script, and that script would in turn access my mysql database. Now I run a cron script that runs this query once every five minutes or so and outputs the result to a text file (so I still use ssi includes, but only include text files not php or cgi scripts). So instead of having these scripts run every time a user visits a page, it does so once every five minutes. Another thing I did was upgrade to php5 and install apc (it's basically a php cacher). Load has gone down a good bit. There's more I can do as I have time, but performance is acceptable now and I have more important things to do (preparing for baby!). Another thing to look at would be upgrading mysql (not for the faint of heart, read the upgrade docs) and using a super-fast feature-poor webserver just for plain html, images, downloads, etc. Let apache handle all the hard stuff, and a much leaner, meaner, faster server handle the easy stuff.
Well, I could write pages, but that should give you an idea of where to start. Check performance, optimize, then upgrade if necessary.
josetann thanks, agree that code comes first, but hey preparing for baby, server and code must really seem tiny on your list now.
If your pages are light and your code is reasonable (the code part is a lot more subjective) then look at a faster server.
I'm hoping to upgrade my oldest and slowest mirror (in the UK) to Sun's (smallest) CoolThreads box, and have been tweaking my code to try to be ready to take advantage of what are effectively 24 CPUs on one chip! Cool is the word! B^>
But right now, even on the slow single CPU that I am hoping to replace, page sizes are ~30KB and page generation time is <1s, with the user seeing some output within about 100ms.
Rgds
Damon
[edited by: DamonHD at 10:13 pm (utc) on May 26, 2006]
If you're on your own server now, I'd check the load at various times during the day (preferably during high-peak hours). I want to keep mine below 0.5 (this is on a linux machine btw). That means an average request from the server will take half a second.
This is not correct: the load value does not represent a time value; it is an indicator of how much the system resources are being utilized in the respective time period. It's rather a hard value to explain; on a one CPU machine, theoretically a value of 1 indicated the machine is being utilised at 100% of its capacity (which from some points of view is an ideal situation because it means the machine is not wasting processor cycles). Depending on resource utilisation, on a typical web server higher values will not always mean that page delivery is (noticeably) slower; I've worked with a 4 CPU server which was still handling HTTP requests effortlessly with a load of 20 or so.
As a rule of thumb though, lower load values are better; load caused by high CPU activity is less problematic than load caused by high disk I/O (which is always the quickest way to kill a server).
Related Wikipedia article:
[en.wikipedia.org...]
Regardless, the main point is that yes, the faster your site loads, the more pages a visitor will likely see, and the more likely they'll click on an ad. The question is, can you make it any faster? A ten page website with pure html and a couple hundred visits a day will do fine on an old P2 with a few dozen similar sites hosted on it. There's no need to start paying hundreds of dollars to get your own server in this instance.
Of course, if you're making a lot off of adsense, I would be tempted to move to your own server anyways. Find a reputable company, perhaps even colocate instead (when you colocate, you own the server and can have it built to spec). Besides a possible decrease in site loading time, you're in 90% control (your upstream provider still has some say, so don't go breaking any laws or spamming). With shared hosting, you're at the mercy of your webhost. Maybe their server will go down and they'll take a while to get it back online. Perhaps they'll fail to pay their provider and get shutdown. Maybe they'll start to overload their server. If you're making hundreds (or more) a day, it's worth it to pay a bit extra to ensure your site won't go down. How much money would you lose if your site was down for a week? Hint, it's more than just seven days worth of adsense pay (if your site is down a week, you may lose some repeat visitors, google ranking, etc.).
Sorry, I can ramble sometimes. Without knowing specifics, I can really go on some tangents.
a super-fast feature-poor webserver just for plain html, images, downloads
If you're on linux, the fastest way to serve static files is to use the kernel HTTP accellerator. It monitors port 80 for GET requests for files, then fetches them directly from the filesystem without ever entering userspace. This saves a bunch of context switching and code runtime.
Let's see if I can find a HOWTO... there's this page [linux-sxs.org] but it's pretty terse. There doesn't seem to be a lot out there yet, but an experienced Linux sysadmin should be able to follow it.
Anything that's not a static file can be handled by a regular userspace server like Apache.
If you don't think your hosting service is already using khttpd, point it out to them, it will give them a significant performance boost for no more than the time it takes to configure it.
Well, millions page views a month isn't a whole lot, but it all depends on the complexity of the pages. In most circumstances, caching will help a lot if your site isn't extremely dynamic.
Heh... I would be happy if I can save to buy my own apartment.
All these posts before mine have pretty much covered all about the caching aspsect. However, my programs require dynamic image processing and generate relatively complex results.
I have a Pentium D 2.8Ghz 2GB RAM 2x80GB RAID1, and I survived both digg & slashdot at the same time.
zCat, how much RAM would you consider sufficient? 4GB? Just curious if I should upgrade mine.
None of my Web servers has more than 2GB, though I'm tempted to go to 4GB for my new Sun box...
Rgds
Damon
zCat, how much RAM would you consider sufficient? 4GB?
Erm, depends... More is always better, but exactly how much you need depends on what services are active on your server and how much traffic you get. If your server is using more than a few Mb of swap space regularly, you need more memory. Watch "top" for a while and keep an eye on the various memory values. Ignore the "free" value (in Linux at least); the "cached" value will give an idea of how much memory is still potentially available.
Swap: 2048276k total, 8796k used, 2039480k free, 916124k cached
What do you think?
What this means, is that instead of making calls to the server/database, the pages are cached as they are called by users for a certain amount of time - the first time in that time period that they are called by a user, the database is queried, but after that the page is cached and treated like a static html.
Can really cut down on CPU/memory calls.
