Forum Moderators: phranque
Unless a client comes to me with his own web host (grr), I like to host sites I develop in one of two shared hosts for ease and cost. Sometimes, my sites take a good 5 seconds to even respond, let alone return the whole page-- I turn on FireFox's LiveHeaders to watch the headers come in. On the other hand, some commercial sites come up almost before I even click Go/hit enter!
Some physical factors are number of hops and bandwidth both on the host and client ends, host server speed, and concurrent access to shared hosting. Other strikes against me: I do php, db queries, htaccess rewrites/redirects when necessary, etc.
Is there some formula or some hosting features to look for when host-shopping? Is it host-dependent? Are there some tests I can conduct to verify? Does a dedicated server make that difference?..
[webmasterworld.com...]
As content management systems and other database-driven sites continue to proliferate, I think this is going to be a problem that every hosting company is going to have to deal with. It's not just a matter of contention, there's also the possibility of busy but badly-coded sites executing database queries at such a rate that other database-driven sites on the same server run really slow and occasionally just grind to a halt.
Server side dynamic pages aren't that big a factor unless they are poorly coded or do heavy duty queries. I have one customer who has millions of records in some of his tables. Complex queries on those tables are very slow compared to queries on public pages, such as searches and details. Fortunately the slower ones are administrative only.
Another factor is of course secure servers, those are always slow. Always implement a method of getting off the https as soon as possible.
- The user's own Internet connection, browser, and browser configuration. In many cases, the browser is not optimized for the user's Internet connection. In most cases, the configuration options to optimize the browser are burried and/or require editing a text file.
A need not addressed by current browsers (to my knowledge) is the ability to adapt to the characteristics of the particular web site being viewed, instead of simply to the user's Internet connection. As an example, a site with a high-latency but high-bandwidth path (example: accessing a site across the world in a country with high bandwidth to the Internet, through a cable-modem connection) can be greatly helped by maximizing simultaneous requests of imbedded images and by speculative fetching of links. In the case of low-latency but low-bandwidth (example: accessing a nearby site through a dial-up connection), these should be minimized.
Of course, the webmaster has no control over this. But you should be aware of how these factors affect the user experience nevertheless. And, it's possible to do some mitigation by detecting aspects of the user's connectivity and adjusting server parameters and/or content.
- Server load. Some ISPs do indeed cram thousands of websites on one server, often without resource limitations on individual sites. Although most sites hosted in this manner present a minimal resource load, it is uncontrolled and unpredictable. One can gain control of server load by using a dedicated server or a VPS. But it's important to use a VPS that limits resource usage, and you should know how many VPSs are loaded per server.
- Burst bandwidth, path diversity, and geographical location. The best hosts are located in large "carrier hotels" with multiple high-bandwidth connections to the Internet, preferably via Tier-1 carriers.
Ideally, it should be located near the center of the network topology for your target audience. (Not necessarily the geographic center.) This is often ignored - probably MOST hosting in the U.S. is either on the east or west coast, while, logically, the best locations are probably in the central part of the country. Historically, the ingress/egress points for international traffic have been on the east and west coasts, and domestic traffic has been routed via east and west-coast hubs. But this is changing.
Dallas, for example, has become a major center for international connectivity, with direct connections to London, Hong Kong, etc.
This is why I choose to host in Dallas. I have run traceroutes to my host from various spots around the country and world, and am amazed at just about every test I run.
Level3 is very agressive about putting in direct high-bandwidth connectivity that bypasses choke-points, so if your audience is international, look for an ISP with Level3 connectivity in a major carrier hotel! As an example, Level3 runs direct links from Dallas to Amsterdam, London, Paris, Frankfort and others. They are equally agressive within the U.S. How about Detroit->Dallas with no other hop in between?
(Sorry to run-on about Dallas, but it is my little secret I am sharing. Not pushing any particular ISP, as there are TONS of them located there.)
Diversity is important, and varies WIDELY between ISPs. Many are at the end of a narrow, two-lane street with a bus that runs every hour. (An analogy, obviously...) Avoid hosts that only connect to 1-2 carriers, none of them Tier-1!
- DNS issues. While this typically only affects a user's FIRST access to your site (within your DNS record's TTL, or time-to-live), the first access in a session is the most important! Consider third-party DNS hosting using IP-Anycast routing technology. This causes the user's DNS requests to be routed to the NEAREST DNS server.
A good DNS host will have servers in at least 3 continents, and in all regions of the U.S.
Make sure you have "glue records". If your site is anything other than a .com or .net, you probably do NOT have glue records, and this will require an extra DNS lookup. You can correct this using a "vanity DNS" setup, where you register DNS servers (you don't have to run your OWN DNS servers - you are just registering aliases for your DNS hosts servers) in the same domain your website is hosted in. On a high-latency connection, glue records can make a noticible difference.
Use dnsreport.com to check your site's DNS configuration for errors and to see if it is optimal.
I will have to look into your dns suggestions-- it sounds entirely in my control, and that's always a good place to begin ;)
