[slscripters] http://vwrsearch.secondlife.com/client_search.php failures, is it being throttled?

[Sasun Steinbeck]

Is there some throttling going on to calls to the viewer search address http://vwrsearch.secondlife.com/client_search.php? This is commonly used for "name2key" type functionality.

From my web domain, these calls are failing quite frequently (returning nothing), but sometimes it works. It's as if it's being throttled. If I make this call from a different domain (my home PC) using the same exact code, it works every time. The only difference is the domain that's making the request. I think my web server domain is being throttled since I do sell some products that call code on my web server that make those http requests, so they're all coming from one domain. Those products typically run through a long list of names looking up keys from time to time. I'm not bombarding the secondlife.com server with a zillion search requests, but it's possible that customers are doing lookups of quite a few names, possibly multiple customers simultaneously, at a rate of 1/second. Is there some throttling going on? This is really screwing up more than one of my products that relies on doing these key lookups.

Please don't suggest that I use a different name2key service, that's not the problem I'm trying to solve here. I'm trying to find out if calls to http://vwrsearch.secondlife.com/client_search.php are throttled from a particular domain or not.

[Nexii Malthus]

Are you making sure to cache any and all results? A key lookup to the SL website should only happen once for an avatar, the next time it should be pulled from a local cache. It doesn't cost much, but it helps significantly.

- Nexii Malthus

_______________________________________________
Click here to unsubscribe or manage your list subscription:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/secondlifescripters

[Fred Beckhusen]

re: is it being throttled?

The answer is 'of course it is, sometimes'. But this a useless
answer, so perhaps the question as to whether it is being throttled
should be re-asked.

"When (fill in URL) is working, or connectionless, broken, 404'd,
giving a totally impossible or illegal message, giving the wrong
message, slow, sending me too much or too little data, is hacked, or
whatever, is the response being properly handled in my application?".

Answer and code for that question and you will be far better off,
because networks are inherently unreliable. The content of the end
provider must always be considered 100% suspect, and ignored, retried,
paused, canceled, queued, or otherwise handled in your application.

Wolfgang Pauli once said "Not only is it not right, it's not even
wrong <http://en.wikipedia.org/wiki/Not_even_wrong>!" Thats a good
thing to keep in mind when you communicate with servers.

TCP/IP only guarantees an end-to-end correct transmission of byte
streams, or eventually an error response. This can still fail for a
perfectly good host, client, and network, because you also have to
consider other layers of the protocols other than just
socket-to-socket. For example, if a host moved by a DNS change to
another IP, and the Time to Live field is set to 5 minutes, then you
expect the LSL script to switch to the new server. But the answer you
will get is not even wrong. And its not right, either. It's an old
response. This is an application level error that the low-level TCP/IP
handled perfectly. The Linden's O/S has apparently been patched to
cache the DNS entries and ignore the Time To Live field in the DNS
record. It could also be your ISP has cached the record. I've seen
LSL scripts still trying to connect to the (old) IP for days.

You just have to design for these eventualities or live with the
consequences.

Ferd Frederix.
http://www.free-lsl-scripts.com

[Markus Hastreiter]

Your name2key service is hopefully doing the caching Nexii already recommended. If it's not then indeed you'll want to either add functionality that caches the name-key pairs if you happen to be in control of that, or use a service that does it for you. The caching will not only improve whatever throttling experience you might have, it will also very likely speed up the turnaround times for requests that happen to be cached.

[Sasun Steinbeck]

Thanks for the tips on caching, which may be useful to a new developer. I am caching all the names, which is now northwards of 100,000 names and growing. All these tips on caching are I'm sure useful to someone unfamiliar with that idea, but do not actually answer my question. Caching does not help whatsoever for a name that's not in the cache, and having uncached lookups fail 90% of the time is a very different scenario than having them fail extremely rarely in the past. When I say "fail" I should have been more specific. In this case I'm not talking about a timeout or other random http/network error, I mean a valid HTTP response that has a blank body, which means that there was some kind of unspecified problem on the secondlife.com end (the only case I've ever seen is due to the fact that the name is bad).

My retry strategy for very occasional network or HTTP error retries is going to be very different than a scenario where 90% of them are usually failing due to throttling. If it's throttling I'm not going to retry in a loop but rather look at some kind of strategy to lower the request rate and avoid the throttle altogether. That avoids the performance issues of doing blind retries over and over so the user doesn't have my scripted product running very slowly as it retries until the throttle opens, which may be never, in that case, since I can't control how many instances of my scripts owned by customers are doing lots of lookups at any given moment. Avoiding the throttle means the calls work 99.9% of the time on the first try, so that would be a much better solution. This is similar to the IM throttle previously discussed, the wrong way to solve that is not the usual progressive-retry-up-to-a-limit technique until it works, but to completely avoid the throttle by metering the rate of requests, plus it lowers the number of requests on the secondlife.com server which of course is the right thing to do.

So... is it being throttled, and what is the rate?

[AnnM...@slfbi.com]

Do you notice problems at similar times every day? I don't know if it
is related but I'm still trying to track down my http error 500 problem.
Symptoms:-
I do about 200,000 or more http requests per day but rarely more that 10
an HOUR from any one sim.
Periodically a large number of vehicles simultaneously start getting
error 500 messages all over SL. Also other supervisory SL and off world
programs will get the same problem so it is not an SL throttling.
The problem only occurs between about 10PM and 2AM Eastern time. It
lasts from 10 minutes to an hour.
Each vehicle does 2 or 3 re-tries spaced about a minute apart but about
10% will fail all 3 times and get shut down llDie().
I have a master monitor that detects the problem and stops all sites
rezzing replacements but that doesn't stop the error 500 events. The
number of vehicles can drop from 150 down to below 50 but the problem
does not go away.
This suggests a timed throttling rather than overload since reducing the
traffic does not relieve the problem.

I contacted the data base host. They are mostly clueless and
automatically suggest upgrading $$$ until you insult them a couple of
times and they run out of boilerplate standard replies.
One finally looked at the logs and said my .php processor was getting
overloaded and I need to upgrade.
HOWEVER the vehicle traffic is constant 24/7 so how come the problem
only occurs late at night when other Internet loads should be minimal?
I told them I would upgrade if that would solve the problem but first
they had to explain the anomaly. I'm waiting for the Monday tech crew
to get an answer.

AnnMarie Otoole