The Web Hosting Blog

Web hosting plans with 100GB of disk space and 1000GB of bandwidth. Do you really need it?

admin — Tue, 21 Oct 2008 23:03:16 +0000

During my 7 years of running a web hosting business, I have occasionally lost customers who state the following reason for why they were leaving my company: “xyzWebHost offers more disk space and data transfer for the same price as your plans“.

That always makes me curious so I end up checking the customers account to see how much disk space/bandwidth their site is using. Almost always, the user’s site is pushing, at max, 10% of the total allotted resources partitioned to the account.

So the big question!

How come so many people are fooled into thinking that just because a company offers higher numbers[in disk space and bandwidth], that they are getting a better deal or more value?

I’m going to let everyone in on some secrets that many web hosts will cringe to know that I am letting out.

Most sites use little disk space and bandwidth - I would say 99% of my customers never reach even half the amount of disk space and bandwidth that is a lotted to them.
No host will let you use 100Gb of disk space and 1000GB of transfer - No shared web hosting provider [charging $5-$15/m] will let you reach your limit. As soon as you use a fraction of your plan, they will suspend you stating the famous ‘CPU limit exceeded‘ line. Don’t believe me? Go ahead, try it. See what happens.

In fact, most of the top web hosting providers around oversell their services so much that it is physically impossible to allow their customer’s to reach the limit. They know that 99% of sites use less than 1GB disk/10Gb of transfer. Do you think they really care about keeping you as a customer if you are using the whole 100GB space/1000GB transfer? You are 1 percentage point to them. They get rid of you, and shove 50+ more customers onto the server bringing in 50x the amount of revenue.

What I recommend you do is consider what really matters:

Forget about disk space and bandwidth - Most plans today are well equipped to handle your website. Your site will most likely use no more than 1GB disk and 10GB transfer.
Consider service above all else - Consider the service level before anything else. Make sure your provider is a reputable company. Here is how you can find a good web hosting service.
Consider price secondly - The price of the web hosting plan is usually a good indicator of the type of service you will receive. If you pay $3.00/m for a 100GB plan, the chances are you are getting a junk service. If you are paying $15/m for a couple GB of space and an average amount of transfer, it will more likely be a higher level web hosting service.

What I really want you to have learned from this article is this: Higher numbers does not mean better value. In reality, the higher the numbers of disk space/bandwidth and the lower the price, the worse off you will be. It is also a good idea for you to get a good estimate of how much resources your site is currently using. I think you will be shocked as to how much space/transfer you thought you were using vs. how much your website is actually using.

CPU limit exceeded warning: from shared web hosting to VPS hosting

admin — Thu, 16 Oct 2008 21:57:20 +0000

When choosing a shared web hosting plan, most people only consider the amount of bandwidth and space that a website will need. However, as time goes on and your website gets more popular, it is common to get the dreaded CPU limit exceeded warning from your web host. After the warning your website almost always ends up suspended/removed from the server.

Why you got the CPU limit exceeded warning

There are a few possible explanations for this:

You went with an unlimited web host - this warning is the unlimited hosts way of telling you that your website is using too much disk space or bandwidth. You actually believed they would let you fill up their server for $5.00/m?
You went with an overselling web host - You know the plans - 1000GB of disk space and 10000 GB of transfer for $3.00/m. Come on now, that’s ridiculous!
The CPU warning is legit - If your website is too popular, no shared web host can allow your popular website to effect the other 100+ customers on the server.

What are your options?

Luckily there are some other options for you that won’t burn a whole into your pockets:

Find a better hosting provider - Find a host with a reasonable offer. Something like 2GB of disk space and 40GB of transfer for $9.99/m sounds good. This host would be less likely to shut you down because they can afford to put less customers on a server than unlimited and overselling web hosts.
Upgrade from a shared web hosting plan to a VPS plan - If your website is a popular one that is resource intensive, this is your only option. Yes it will cost you a lot more than a shared plan, however a VPS plan will be less expensive than going straight to a dedicated server.

What is a VPS plan and how much is going to cost me?

VPS stands for Virtual Private Server. A VPS provider will divide up a dedicated server into 5-10 partitions. They provide you with a guaranteed amounts of disk space, bandwidth, and most importantly CPU and RAM resources. This is perfect for your resource intensive site. Even if you reach your max amount of allowed CPU/RAM, your host won’t shut you down. The end result will just be a slower loading website when you reach your limit. After all, a slower loading website is better than no website at all, right?

There are two types of VPS plans - unmanaged and managed. Unmanaged plans range from $20-$40 a month. If you know your way around a Unix based machine, this will be perfect for you. However, if you have no clue as to what you are doing, you will need to go to a manage VPS solution. These will be more expensive than the unmanaged plans because now they have to devote system administration to you as well. Expect to spend $50/m + for a quality managed VPS plan.

90% of the time the dreaded CPU warning is a unlimited and overselling hosts way of telling you to go somewhere else. There are occasions that your website could actually be too popular for a shared web hosting environment. If this is the case, I suggest you upgrade to a VPS web hosting plan. This will solve your problem, atleast for awhile…

Researching your web host before signup will save you headache, time, and money.

admin — Fri, 10 Oct 2008 22:09:58 +0000

Research? I know, I know…research sucks. But spending 5 minutes researching your web hosting provider selection, will save yourself from so much frustration, headache, time, and money. In my opinion, researching your web host before you signup is the best 5 minutes you will ever spend during your search for the perfect web host.

How to find the best reviews on a host

Without a doubt, the easiest and best way to find info on your web host is to use WebHostingTalk. WHT is a really large and active web forum that discusses almost every area of web hosting that I can think of. If a web host exists, a review for them will be found there.

Shared web hosts - If you are looking for reviews on shared web hosts, check out the general web hosting forum.
Reseller web hosts - Need of some reseller hosting reviews? Check out their reseller hosting forum.
Dedicated servers - They even have a section for dedicated servers if you need something to that scale. I use this forum when finding a suitable datacenter for my dedicated servers.

Analyzing the reviews

Don’t believe every review you read on this forum. Users often use WebHostingTalk to blackmail a web host by creating a ‘SoAndSoHosting sucks do not go with them thread’. I have also seen web hosts signup with a different user name and act like they are a satisfied client of the company. People definitely realize that WHT can either make or break a company. I have seen many companies become popular and successful through this forum.

So anyway, what I suggest you do is use the search function and find as many recent review threads you can on your web host selection. If 50% of them are good reviews, than it is probable the host is a good company. Even the best hosting companies in the world still have unsatisfied customers. Its just not possible to please everyone.

Unsatisfied customers will often go out of their way to make sure everyone knows about their bad experience. This is why you often see more bad reviews on companies than good.

Don’t believe web hosting review sites

One thing that I suggest you stay away from are those web hosting review sites. Most of them have motives for creating a review on a certain host. A lot of these sites use web hosting affiliate programs in order to make money on the sign ups they send to the host. So these reviews are often funded by the web hosting companies themselves making for a very biased review. For this reason, I suggest you stay away from them.

Just do your research and you will find that great web hosting provider. Spending 5 minutes now, will save you hours and hours of frustration and could also save you money if you monetize off your website.

Convinced that all web hosting providers suck? Tips on how to find a good hosting service.

admin — Wed, 08 Oct 2008 22:24:21 +0000

With the thousands of web hosting companies out there, it takes trial and error and even a little skill to find the best ones. Most unexperienced users often have to go through multiple hosting providers before they figure out how to spot the bad ones and how to spot the good ones. If you are convinced that all web hosting providers suck, this tutorial is for you.

Tip #1: Don’t be cheap.

When it comes time for someone to chose from the endless list of web hosts, a newbie will often try and find the cheapest hosting provider possible. People tend to think of web hosting providers as all being equal, with the only difference being the price and the amount of space and bandwidth that is included in the particular plan.

However, web hosting is just like any other product or service in the world:

The amount you pay for your hosting plan is directly related to the quality of service you will get. The less you pay, the worse the service.
It’s sort of like buying a new car - You wouldn’t expect to get a brand new Mercedes for the price of a Honda, now would you?

Tip #2: Testing the waters

One way you can get some sort of idea how a web hosting providers service is to test the waters before you sign up.

Open up a ticket or send an email to tech support asking a couple questions. Perhaps something related to technical support - “Do your servers have the GD libraries installed?” - or - “Would it be possible to get PHP safe mode disabled on my account if I signup?” This is great way to tell how much a company values their technical support department based on how long it takes them to reply.
Some web hosts offer free trials or money back guarantees - Try your web host out before having to signup for them. Just be sure not to transfer your live site over until you are sure they are a decent company.

Are your expectations too high?

This is what I think the number one reason why people think that all web hosts are bad. Do you expect 24/7 phone support for $4.99/m? Do you expect that service to be flawless for that same price? Should the plan come with 100GB of disk space and 1000GB of transfer? If this sounds like you and only want to pay $4.99/m for it, then be prepared to be let down. There would be no way for a company to turn any profit by providing all the above for $4.99/m.

In order to find a quality web hosting service, you need to be concerned with the service itself and not how cheap of a price you can get. Granted, there are some hosting services that can provide a decent service for at a low price. But for the most part, the amount you pay your web host is directly related to the service levels you receive.

Setting up the logout functions to clear the user session ID

admin — Sat, 04 Oct 2008 00:31:10 +0000

PHP & MySQL Login Tutorial Series
Pt1: Introduction
Pt2: Setting up the database
Pt3: The front end and user validation
Pt4: The code to privatize a page
Pt5: Logout function and clearing the session ID

Part 5: Logout functions

Our final function is the logout function that will wipe our session. That function is simpler and looks like this:

function logout() {
$sessionid =$_COOKIE[test_account];
@setcookie (”test_account,”,time()-99999, ‘/’, ”);
mysql_query(”DELETE FROM user_sessions WHERE sessionid=’$sessionid’”);
}
?>

We first grab any session id out of the user’s submitted cookie. We then delete the cookie on the user’s computer by setting the cookie expiration date to sometime in the past (effectively deleting it), and we finally delete the session record from our database.

Before we can finish off the program we have two more tasks. The first is to throw an error message if the user enters invalid login credentials, and the second is to print out a greeting to the user if they’re logged in. Replace the HTML code from before with the following:

if($userid > 0) { echo “Welcome to our site, user #$userid (Click here to logout)”; } else {
if($login_status != ” && $login_status == 0) { echo “Invalid username/password combo.
”; }
?>

We first to check to see if our status function call returned a user id. If it did we can print out a welcome to the user, giving them his or her user id. We also provide a link for logging out; simply call the same page with “logout” specified as a URL GET variable to log out. If we don’t have a user id, we’ll print out the login form. We also check the login_status variable to see if there was an error. If there was we’ll print this out to the user.

This tutorial covers the basic concepts of a user login system, however it certainly doesn’t cover everything. There are many websites on the internet that can assist you with the specifics of setting up a database table, basic programming concepts, and anything in between. The full sample program can be found here. Note: In our example we assume you already have a connection to the database established, however sample.php includes the basic MySQL database connection functions.

How can a blog help your main website? Setting up a blog to increase web traffic.

The validation code for the pages you want private.

admin — Sat, 04 Oct 2008 00:30:31 +0000

Part 4: Privatizing your pages

Now let’s look at the status function. This function will be called on every page we want to protect. It will check to see if the user has an active cookie, and will match the session id in the cookie to our session table. If there is a match, the user will be logged in. The function looks like this:

function status() {
$sessionid = $_COOKIE[test_account];
$oldtime = $time() - 3600;
$query = mysql_query(”SELECT * FROM user_sessions WHERE sessionid=’$sessionid’ AND timestamp>$oldtime”);
if(mysql_num_rows($query) == 1) {
$info = mysql_fetch_array($query);
return $info[userid];
}
return 0;
}
?>

First we’ll grab the session id that’s stored in the cookie “test_account.” The variable $oldtime is the oldest time the cookie could have been created. In this case that’s any time over the previous hour. The 3600 seconds must match the number of seconds in the setcookie function. We then query the session table for a match. If we find one we can pull the userid out of the session table and we’re logged in. Otherwise we return a 0.

Depending on your type of site, you may want to store frequently-used information in the session table for easy access. In this case, should we want to pull down the user’s username, we could use the userid pulled from the session table and then query the user_accounts table and match the user id for the account in question.

Next -> The Logout functions

No related posts.

The frontend form and the PHP user login validation script

admin — Sat, 04 Oct 2008 00:30:09 +0000

Part 3: Frontend form and validation

In this example we’re going to have a simple page that will display username and password text fields if a user is not logged in, and a simple greeting if the user is logged in. The HTML form code for the user/pass login should look something like this:

This HTML will give us a simple form with two fields named username and password. When a user enters the login info and clicks the submit button, the page will reload. Now we need to add in the PHP to retrieve these credentials when the page is loaded. To make sure everything works, add all of the PHP code to the top of the document (as seen in sample.php). To simplify the tutorial we’re going to give you the code for logging in, logging out, and checking user status in one snippet, however we will not be discussing all of it just yet. Here is the code that will regulate the user activity:

if($_POST[username] !=” || $_POST[password] != ”) {
$login_status = login($_POST[username], $_POST[password]);
} else if($_GET[logout]) {
logout();
}
$userid = status();
?>

Note: The above code must appear before any output in your document. If there is ANY output prior to this code being executed, you will receive errors when cookies are trying to be set during login.

We first check to see if the user is logging in, in which case we’ll call the login function, and we’ll also check to see if they’re logging out, in which case we will log out the current account. Finally we check to see the user’s status. If the user is logged in the userid will equal the user id. Otherwise it is equal to 0. Now let’s look at the functions we call in the above code.

The first function we’ll check is the login function. This is the meat of the program that will check user credentials. The code looks like this:

function login($username, $password) {
$username = addslashes($username);
$password = md5($password);
$query = mysql_query(”SELECT * FROM user_accounts WHERE username=’$username’ AND password=’$password’”);
if(mysql_num_rows($query) == 1) {
$info = mysql_fetch_array($query);
$userid = $info[userid];
$sessionid = md5($userid . time());
$time = time();
@setcookie (’test_account’, $sessionid, $time+3600, ‘/’, ”);
mysql_query(”DELETE FROM user_sessions WHERE userid=’$userid’”);
mysql_query(”INSERT INTO user_sessions (sessionid,userid,timestamp) VALUES(’$sessionid’,'$userid’,'$time’)”);
return $userid;
} else {
return 0;
}
}
?>

We begin by reading in the username and password. We used addslashes() to help protect against SQL injection attacks. Generally you wouldn’t have single quotes in usernames, however if someone tries to break into the system this will help protect you. Next we encrypt the password with MD5. MD5 is a hashing algorithm that will scramble any text and return a 32-character string. Whenever you add a user to the database, make sure the password is saved as a 32-character MD5 string. This will guarantee that anyone who may break into your database will not be able to steal your users’ passwords. Again while this is not foolproof, it does help protect user data. The idea is that instead of matching two visible passwords, it’s better to match a scrambled password with the real password’s scrambled counterpart. Since MD5 will always return the same 32-character string for a specific input, we can guarantee that the MD5 hash stored in the database will always match the MD5 hash of the correct password. If you do not wish to encrypt your passwords, simply remove this line from the login function.

We then check the database to see if a user exists with the entered username/password combo. If a user does not exist we’ll return the integer 0. This is arbitrary, however the number must remain consistent throughout your program. If the user does exist, we’ll fetch the user id number. We then create a session id (again with md5). Note that we’re not only encrypting the user id as the session id, but we’re also concatenating the current timestamp to the user id. This will make it near-impossible for a would-be hacker to guess an active session id. You can use other salts to protect the session id even more.

After we have our session id we will want to store it on the user’s computer. To do this we call the setcookie() function. The first parameter, “test_account,” is simply the name of the cookie. Again you can set this to be whatever you want, however it must remain consistent throughout your code. The second parameter is our cookie contents, in this case the session id. It’s important that we only store non-identifiable information in the cookie. If we were to store something such as the user id or a username, it would be very easy for the would-be hacker to spoof the cookie and gain access to your user accounts. By using a session id, the hacker has to know the id in order to spoof; with our MD5 encryption this becomes difficult and makes it harder for the hacker to exploit your script. The third parameter is the cookie expiration time. $time+3600 is the current time plus 3600 seconds, or one hour in the future. Finally we set the directory the cookie is valid for. It’s sufficient to leave this parameter set to “/”.

After we set the cookie we need to clear out the session table. First we will want to wipe any old sessions for our user. We then insert the new session so we have something to match the cookie against whenever the user returns to our site.

Next -> Privatizing a page on your website

Web hosting - the last form of free speech in America?

Creating the database for your PHP & MySQL login script

admin — Sat, 04 Oct 2008 00:28:43 +0000

Part 2: Creating the MySQL database

Before we get to programming, let’s setup the databases. You will need to create two different tables—one for user accounts and the other for sessions. Setup the tables as follows:

Table name: user_accounts
Field 1: userid, int(10), primary key, auto_increment
Field 2: username, varchar(10)
Field 3: password, varchar(32)

Field 1 will store our user id number and will be a primary key for unique user identification. Field 2 is our username with a maximum of 10 characters. The number of characters can be set at whatever you’d like. Field 3 is our password field and, for this example, needs to be a minimum of 32 characters. You can use a larger size, however all passwords will be 32 characters in length.

Table name: user_sessions
Field 1: sessionid, varchar(32), primary key
Field 2: userid, int(10)
Field 3: timestamp, int(12)

Field 1 will store our temporary session id and must be 32 characters as well as a primary key. Field 2 is our user id and its size must be equal to the size you selected in the user_accounts table. Field 3 is our time field. There are several ways to store a time in a database, however we will be storing the Unix timestamp.

Next -> Front end + User validation

No related posts.

Simple PHP/MySQL user login tutorial. Make parts of your website private with a login.

admin — Sat, 04 Oct 2008 00:27:22 +0000

Part 1: Introduction

Sometimes it’s important to restrict access to certain parts of a website, and the best way to regulate this access is through a user login system. This article is going to cover the creation of a very simple login system that will help get you started. This system is by no means 100% secure, so we do not recommend using it in a production environment, however we will examine one of the ways a login can be created and we’ll also look at some of the pitfalls of such a system.

Before we begin, let’s establish the pseudocode of our script and walk through the general process of a login. First, and most importantly, we need a user account. This will include the user’s login identification number, a username, password, and any other credentials we may want such as access levels or email addresses. To keep this simple, we’ll stick to user id, username, and password. When a user enters his or her login credentials on your site, we will have to verify the credentials and then establish some means to keep track of a user’s login status. Remember, whenever someone visits a webpage, that page is always loaded as if it’s the first time someone has been on the site. We need a way to tell the site who the user is so that the site can make adjustments for the logged in account.

There are essentially three different parts to this login system. The first part is the PHP code we’re going to write that will regulate the user access. We’ll also need a database to store both the user account information as well as temporary session information that remembers what accounts are logged in. The latter can be setup several ways, including the use of PHP sessions, however for this example we’re going to store the sessions in a database. The third thing we’ll need is a way for the user’s computer to identify itself. For this we’re going to store a cookie on the user’s computer that will be sent to our website every time the user accesses a new page.

Let’s begin creating the code. If you want to test this code on a working site, we suggest you create a separate user.php file (or equivalent) that will store all of the user functions. In this example we’ll simply reference all of the different parts necessary. To view the final working code as it should appear on a site, go to http://blog.readysetconnect.com/sample.php.txt.

Next -> Setting up the MySQL database

Todays unexpected Google PageRank update. New pageranks for September 08

admin — Tue, 30 Sep 2008 00:05:02 +0000

If you haven’t noticed already, Google has just updated it PageRank for September 2008! I am happy to say that my main website, ReadySetConnect has gone up a rank from PR4 to PR5. I am also pleased to say that the PageRank of the web hosting blogs stayed at PR4. I was actually expecting it to drop due to the fact that I enabled do-follow for comment links.

Every time Google updates PageRank, I learn something new. During the update before last (August 08) I was really mad because my PageRank of my main site dropped form PR5 to PR4. I really got my hopes up while waiting for the August update - I thought for sure that it was going to increase to PR6 instead of drop. Before the update I was working hard every to nab as many links as I could - from PR0 to PR7. Then the update came and my whole PageRank world came crashing down. That is when I stopped caring about gaming my site’s PageRank. I found out that day that Google is insanely good at analyzing websites and they can tell very quickly when your website is getting some abnormal attention.

The great thing about not worrying about PageRank is that you don’t build up expectations only to be let down. When I noticed today that I moved back up to PR5 I was surprised and happy because I was not expecting it nor did I even care about PageRank at that point.

All I can say to anyone who experienced a PR drop is to try and not worry too much about it. Try to keep in mind that even though your PR may have lowered, it doesn’t mean you will get less traffic from the search engines. Even when my main site went from PR5 down to 4, my search engine referral traffic stayed the exact same. PageRank is just a number, and not how valuable your site is. I also think that the more you try and game your PageRank, the worse off your website rank will be. Just build back links to your website naturally and slowly. I believe this is the key. If you all the sudden start getting these awesome high PR links out of nowhere, Google will start to get suspicious because it is not a normal thing for this to happen.

Just keep working at it and don’t get discouraged. I know that I was when I dropped rank but just remember you can only go up from there. Things could be worse you know -Atleast you didn’t get banned!