Today we announced significant improvements to the speed and quality of domain searches conducted using OpenSRS. With these enhancements, your existing integrations will work faster, as will searches using the Reseller Web Interface. But what I’m really excited about is the continued improvements we have made to our domain search over the past two years, which now allows you to offer an advanced domain searching system that will increase sales of both domains and other web hosting services.

A little bit of background

The methodology I refer to as “domain search 1.0” is unfortunately employed by most web hosting companies today. It is an old, archaic way of thinking about domain search. Common symptoms include:

• Forcing potential customers to enter ‘www.yourname.com’ search strings;
• Not allowing customers to register ccTLDs, or even gTLDs not named .com, .net or .org;
• The absence of suggestions for related search terms.

The most common objection I hear from web hosting companies is they don’t see any value in paying attention to domain name search, until I explain domain search 2.0.

Domain search 2.0

The domain search 2.0 approach treats domain names like the key component they are to the web hosting sales process. Virtually every web hosting company puts domain search front and centre on their website, but the technology used to power the search is often archaic. Domain search 2.0, on the other hand, treats the domain search box like a “magic box” – that is, an open, free-text box that will accept any input and spit out highly relevant domain names.

Our research shows this not only greatly enhances the end user experience, but can lead to a 10 to 15 percent lift in domain name sales if implemented properly. It also results in sales of more value-added services by attracting higher-margin customers.

How does it work?

The key to domain search 2.0 is our powerful NAME_SUGGEST call, which we’ve been iterating upon for more than two years. After our announcement today, it contains four key components:

• Domain name lookup: The “lookup” parameter will take any text and turn it into a domain name search, whether you enter “www.hockey.com”, “hockey league” or “hockey@league.com”.
• Domain name suggestions: The “suggestion” parameter will quickly return results of available names based on the original query using technology from DomainsBot, the industry leader in domain search technology. A new feature now allows you to also specify language if you choose to do so, enabling results to be returned in English, French, Spanish or Italian. Our research now shows that up to 15 percent of registrations using domain search 2.0 are from our domain name suggestions.
• Premium names: The “premium” parameter checks our premium names database of over one million names to see if any related names are for sale on the domain name aftermarket. As of today, suggested premium names are also displayed by DomainsBot, leading to a much better search experience.
• Personal names: A new “personal” parameter also allows you to now search for names associated with our personal names service as well.

We’ve also baked in a new “max_wait_time” parameter that lets you specify the number of seconds that the NAME_SUGGEST command can run, and return as many results as can be found in that time period. This will allow you to build real-time, AJAX-enabled domain searches if you choose to do so.

Putting it all together

Have you thought about your domain search lately? We now have the speed, tools and data to equip your business with a high-powered search that will lead to more sales. There’s more information on our website.

Looking for some more techie information about the new API?

Look no further! Read this post and see some code examples. And to dig even deeper, the Developers/API Forum is the place to be.

This is a quick example on how to use new features of the NAME_SUGGEST API lookup. As mentioned in my previous blog post, we added a new feature to the API that allows you to specify amount of time that you’re willing to wait for results. You would do it something like this:

{
protocol => 'XCP',
action => 'name_suggest',
object => 'domain',
attributes => {
searchstring => 'food toronto',
services => [ 'lookup', 'suggestion', 'premium',
'personal_names' ],
tlds => [ '.com', '.info', 'net', 'ca', 'co.in', '.co.uk', '.es' ],
max_wait_time => "1",
}
};

This search will check a limited number of TLDs (as specified in the call), but it will check regular lookups, name suggestions and premium names for each. Behind the scenes, all these checks will happen in parallel, after hitting the local cache and registry zone files that act as a secondary cache.

The parameter max_wait_time is the new feature. In this case, it means you’re willing to wait one second for response (as measured in our system; the total time for a response will include the roundtrip for the data to travel the Internet). We will collect all results that we can in that one second time period and return the results. The response will look something like this:

{
'protocol' => 'XCP',
'response_text' => 'Command completed successfully',
'is_search_completed' => '0',
'search_key' => 'Ln0ahqiOQ7H3Vab7sURVIronOks',
'action' => 'REPLY',
'response_code' => '200',
'attributes' => {
'lookup' => {
'count' => '10',
'response_text' => 'Command completed successfully.',
'response_code' => '200',
'is_success' => '1',
'items' => [
{
'domain' => 'foodtoronto.com',
'status' => 'available'
},
{
'domain' => 'foodtoronto.info',
'status' => 'available'
},
... (response cut here for clarity)

Now, many of the results will be determined and returned in one second, but it’s likely not all of them can be looked up in that time frame. However, even after we return result set, we continue collecting the rest of the results in the background.

If you’re building an AJAX interface, here is a neat trick you can use: Look at the parameter we returned called search_key, and you can reuse it:

{
protocol => 'XCP',
action => 'name_suggest',
object => 'domain',
attributes => {
'search_key' => 'Ln0ahqiOQ7H3Vab7sURVIronOks',
max_wait_time => "2",
}
};

In the call below you’re now using the search key parameter, and retrieving results that have already been collected for you. And you are also specifying that you’re willing to wait another two seconds. If you introduced some sleep() on your end before sending the second API call, you can drop this time too. At this point you will receive back something like:

{
'protocol' => 'XCP',
'request_response_time' => '0.002',
'response_text' => 'Command completed successfully',
'is_search_completed' => '1',
'action' => 'REPLY',
'response_code' => '200',
'attributes' => {
'lookup' => {
'count' => '10',
'response_text' => 'Command completed successfully.',
'response_code' => '200',
'is_success' => '1',
'items' => [
{
'domain' => 'foodtoronto.com',
'status' => 'available'
},
{
'domain' => 'foodtoronto.info',
'status' => 'available'
},
{
'domain' => 'foodtoronto.co.in',
'status' => 'available'
},
... (response cut here for clarity)

As you can see, another important addition is the new response parameter is_search_completed = 1. This value indicates that you have received the full result set, and that there is nothing outstanding. As long as there are still results to be obtained, is_search_completed will be 0, as in the first example…

Hope this helps. You can always visit the Developers/API section of the OpenSRS Forums to learn more about coding to the OpenSRS API.

I wanted to talk today about a few improvements we’ve done to our check-availability API functionality, also referred to as domain lookups.

In summary, we’ve made a number of improvements that will make check availability much faster, whether you’re using RWI or the NAME_SUGGEST API. If you’re integrating with our API now or in the future, NAME_SUGGEST is the call to use to take advantage of all the advanced features and speed improvements.

Warning: Geek Content Ahead

And, now, for geeks in the audience, here are a few more details…

Historically, lookups have been done sequentially in OpenSRS. Whether you were using the RWI or API, your choice was to request lookups one by one, or give us a number of TLDs, and we would check them one by one. In a Worst case scenario, you could wait as long as 60 seconds for lookup of all TLDs, name suggestions and premium names to be returned.

Well, that has all changed now. We’ve completely re-engineered the OpenSRS system for doing availability checks, and we’ve put a big honking internal lookup service in place that does number of pretty neat things:

1. All that work that used to happen in sequence, is now happening in parallel behind the scenes.
2. There is a new cache in place that stores previous lookups for a short period of time to enable very fast repeat searches.
3. We pre-load and regularly update zone files from the most popular of registries, and make this information available to the system as secondary cache.
4. Not only are all TLDs checked in parallel, but all related services are parallelized, including name suggestions and premium names lookups.

With the new system, we can handle over 8,000 concurrent requests, and have several hundred concurrent processes running at any given point. And this is just a beginning, as system is very scalable!

Working with our partners

To give you a sense of the painstaking engineering that went into this piece of the system, we worked hard with our name suggest partner on optimizing their API. By implementing our suggestions, they’ve cut average size of their API response from 177KB down to 0.6KB. Yes, there’s no typo there–that is less than 0.5% of initial size!

Additionally, we trimmed milliseconds wherever we could. The round-trip for name suggest call
has dropped from 1.1s to 0.5s, indicating that majority of this is processing time for name-suggestion engine spin.

What’s the payoff?

So what is the net result of all this? If you were to do lookup before for all gTLDs, ccTLDs, name suggestions and premium names, it would have taken about 60 seconds before. Today, with the new API system, you can expect back a complete set of results in around four or five seconds!

Basically, lookup nowadays will take as much time as slowest TLD. If you’re not selling all TLDs (and for reference .es and .in are some of the slowest we’ve seen), your response is likely to be even better that that. To get most often requested gTLDs, your experience will be around one or two seconds most of the time.

Max wait and search keys

And if you’re an API integrator, it gets better. When sending an API command, you can now specify the maximum amount of time you are willing to wait for results! We’ll time ourselves, and give you all the results we’ve been able to collect by that ‘deadline’. You can use this to make a really snappy interface at the expense of maybe not getting few results here and there.

I’ll follow up this post with another that will show you how to do it in the coming days.

As well, should you be building Ajax interface, you can make it both snappy and complete. Just send us two or three calls! With the first one give us one second, and get back the the fast gTLDs, and suggestions. Then redo the same query a few seconds later to pick up rest of the results. And maybe add one more call five seconds later, just in case…although the API will tell you if result set is complete, so you might not even need that last call.

In reality, there are number of strategies you can use with this feature, but I hope you see the potential. It’s powerful, but not complex, and it will enable you to build that snappy page, with a feel-good customer experience where things are just flying.