customizing, using REMOTE HOST

[jcmoon]

There are a few special visitors to our site that we'd like to show lower prices. Being who they are, they'd qualify for volume discounts, so putting that front-and-center for them (while not doing so for the rest of the planet) would be beneficial to both parties.

What I want to do:

Whenever a visitor comes to our site with acme.com in their REMOTE_HOST, I show an extra column on our listing pages, and an extra price on our product pages. In each case, I make it stick out, visually, that this price is a special one for them.

The problem:

REMOTE_HOST only shows an IP address right now. To get the real Hostname, I must turn on DNS Hostname Lookups. And if I do, that's a 20% blow to server performance. Bad bull.

One solution:

I can turn it on (in a .htaccess file in the cgi-bin directory), do the lookup, and then turn it back off (according to emails with Tech Support). I could probably have a script do this. I would intend for that script to do this for every visitor ... perhaps even for every page request.

Problem with that solution:

If I have a fair amount of traffic, that'll still likely hit performance, and if many instances of the script try to mess with that file at once, it might lead to unpredictable results. I could save horsepower by only doing it once per IP address per 90 days, but that would require saving this information somewhere, and all the associated overhead with that (text file? MySQL?)

Advice?

Have y'all mulled over these issues before? What's a good way to get the Hostname for an IP address, but without a blow to server performance?

For the record, most days this site sees 7-12 thousand page views. Each page view the subroutine would be activated to find cached info on the visitor, or to find it directly. Given normal traffic patterns, that's a page view every few seconds during peak hours.

[radix]

You could find IP ranges for the host names you expect (unless the blocks are too excessive) and store them. Then your script could render the output.

[jcmoon]

That's true. I could have it watch for IP addresses near those I have, and if it finds them, either do the lookup that one time, or log it somewhere for me to do it later. Hadn't thought of that ...

[Drag_Racer]

set up a cache DB, if the ip is in your db, resolve it from there, if not then do a lookup and store it in DB

at first you'll see some overhead, but as your DB is populated then things normalize

[vincevincevince]

set up a cache DB, if the ip is in your db, resolve it from there, if not then do a lookup and store it in DB

That is a very good solution. In addition, I'd want to turn off the lookup once you've got your key customers in the cache, and then trim the remaining cache down to just those customers.

I'd be careful about this as a general strategy as:

Some staff may order from home (resolves to ISP)

Some/all IPs in company may still be assigned to ISP (won't help identify the company)

Some IP addresses assigned to the company may be used for non-company business (lunchbreaks / permabreaks)

[balam]

Expanding on Drag_Racer's & vincevincevince's suggestion...

Consider adding a field in your DB for aging. Store the date that you did the lookup along with the IP address. Do your lookups from the DB as suggested, but also compare the current date with the stored date. If the date differs by, say, 60 days, do not trust your stored lookup; re-lookup the hostname.

IP addresses aren't carved in stone; addresses can be reassigned, customers can switch providers... If you invalidate your cache data after a certain time has passed, you should decrease the chance of displaying volume pricing to a non-volume client.