Recently you have come under much criticism that the unruly character’s within Sl have begun making the experience of Web 2.0 far less enjoyable then it should be. I have one suggestion although I can understand it would be a tall order. If you want to see SL succeed as an enterprise and continued phenomenon, you need to stop thinking about it as a social experiment and more as a business venture. Due to the nature of what you’ve created many subscribers have established businesses replacing their RL income. This in itself is testament to the social accomplishments of SL. However in a way, you are gods in this virtual world. You have the ability to see and hear all. As a matter of fact you can even hear people preying by themselves at their SL bedside. My point is this, businesses have already started to become weary of opening up shop in SL in major part due to recent attacks from malicious predators. its about time to STEP UP AND SHOW SOME SAC. Harder lines need to be taken with these miscreants. This, Im sure, can be done without punishing the innocent. But you could find yourselves being blamed for issues you could have solved had you had the will to do so. Perhaps more resources need to go into creating a security team.

Just a thought,

Kristofer Stringfellow

In my 1st life, I work for the small company that developed Efficient XML, the basis for the emerging web standard for binary XML. It was designed to address XML’s performance issues and may be of some help to you. You can find out more about the standard at:

http://www.w3.org/XML/EXI/

You can find out more about the technology and/or download a copy to try at:

http://www.agiledelta.com/product_efx.html

Hope this is helpful! Please contact me if you want more info.

MYSQL was brought up by someone implying they were using it, and I latched onto that in my diatribe against using it in this context (no, still not disparaging the MYSQL, no need to flame me here people).

The use of XML is implied in the original post. If you’re talking about “a cloud of web services” you’re talking about xml messages over http in almost all sense of that phrase.

I don’t doubt there are THEORETICAL speed gains to be had by using a customized or non-standard messaging architecture rather than using standard xml based messages transmitted over http as in web services. You can reduce the traffic size — maybe even considerably reduce it — by doing highly customized messages and even highly customized protocols. HOWEVER, by using the standards, you can apply off the shelf software to vastly better manage all that traffic and the gain you get by being able to use production quality tools to handle the data will in many cases vastly outweigh the real world benefits you can gain from rolling your own stuff — unless you’re as good at writing your own as all the companies competing to produce the tools for web services. That’s unlikely.

By moving to a standard like web services, LL gains the ability to “plug in” new technologies for compression, encryption, load balance, redundancy, network traffic shaping, caching, testing, reporting, and even development that they’d have to fit together or even hand craft if they use a proprietary means of sending those messages. Thus, the smaller traffic represented by the customized message architecture is not helpful when all the customized stuff done to make it work can’t scale well.

Using the tighter, proprietary messages would help SOME small subset of users who are individually suffering for poor bandwidth problems connected to SL. In reality, most bandwidth issues are happening as the thousands of users and their data are aggregated into the data centers and the networks and servers in those data centers. That data center congestion is where the packet loss is happening. I see this all the time in my work with VoIP.

By using the standard web services based architecture, LL can much more easily distribute processing servers, cache servers, front end routing servers and so forth across many data centers at different top tier network facilities and handle the requests from each client at the “closest” data center in terms of network latency. (IOW the data center currently responding fastest to ping without packet loss).

The ultimate goal in scalability for a project like this one in which a key goal is to keep control centralized and treat all end client requests as distant as possible from the definitive data source by answering those requests from pools of cache and lookup servers located as close to the end client connection as possible. For those requests that aren’t cached or must be done in real time (financial data, land data that changes frequently, etc.) the requests can be aggregated at the cache servers.

Once this architecture is in place, there are further opportunities to radically help the cache process. Here are a few ideas (I hope some Lindens are tracking this).

1. Add a minimum TTL flag to all elements. As a designer and landowner, I can flag the store itself, the walls, textures, etc. — all the long term elements — with a TTL flag indicating they do not change frequently. If I create a shirt that I am selling, I can set the TTL flag on the shirt to NEVER change. If I do make a change, I will give the shirt a new universal id — it becomes a new shirt, not a change to the old one. Keep in mind, I’m not telling the server that the same shirt is always in the same place — I’m only telling it that when it comes across that shirt — no matter where it is — that it will always be the same. Think of all the “no modify” items out there. If they’re “no modify” then clearly they can usually be set with a ttl flag indicating they don’t change frequently.

This would allow the cache servers to not look back to the inventory database for all the items that don’t change. Not only could the cache servers not look back to the inventory server for items that it has seen before recently enough that their “ttl” is still valid, it means you could take all the stuff (which is possibly most stuff) that doesn’t change and reference it on COPY servers that update in the background from the primary server — because the servers do not have to contain up to the second authoritative data on the object. It means you could greatly reduce the number of lookups that have to make their way all the way down the funnel to the central inventory server.

2. Establish positive credit. Currently, transactions involving L$ all have to be cleared as safely as if you were withdrawing a hundred bucks from an ATM in 1st life. There are classes of users however, who have payment information on file, have large balances in their L$ accounts, or who have been verified members for a long time. Based on this, a credit score could be generated which allows transactions to be completed for many users without verifying funds immediately in the case of transactions up to a certain size. The size would depend on the various criteria that make up that credit score. In these cases, the debit transaction could be given lower priority and could catch up a few seconds or minutes later. We’re not talking about a huge risk in terms of real dollars here for the Linden’s, not when an acceptable delay time of a few seconds or minutes could mean a thousand times better efficiency and for all transactions overall. I don’t have the stats to know what the average transaction size is, and how many of those average and below are made by people who could be classified as an acceptable risk for a delay of up to 5 minutes, but if you could make the criteria that they had to be logged on longer than that maximum delay time (say 5 minutes) to the same caching server, and that caching server only allowed one or two delayed outstanding transactions at any given time, the amount of potential damage that could be done would be significantly limited in terms of real dollars, yet would get those transactions out of the way of the ones that need real time validation. A maximum delay of five minutes sounds trivial, but the pooling and prioritization effect you can get with it is huge.

I’m sure there are others, but those are big deal ones that would really expand the scalability of the whole system in an incredible way.

a) HTTP is no synonym for XML. XML is just a way to deliver arbritary data to a different environment (so does JSON!!!), the way data is delivered may be arbritrary. Information in binary is just as great.

b) MySQL is powerful if used without server-client-paranoia. But it doesn’t say that it is used here. There are better, even distributed database network applications that may fit better here (looking at performance of MySQL on 6.000.000.000.000 entries WHAHAHAHAHA ^^)

c) Internet Explorer 7 is from Microsoft. They do actually cooperate with Linden Labs, but giving their browser source? No way! If they include internet, they may use Gecko/KHTML/MacHTML-related stuff, but not IE7… Also HTTP has nothing to do with a web site. A web service is a listening daemon waiting for incoming data, responding with intelligent answers and waiting for the next query. That this may serve websites is a special daemon, but not the LLMessageSystem.

If one has to add further binary data there he would have to create a POST-request. Let me explain this junk, it causes to be an arbritrary additional header (not only for the sender, also for the reciever) to be sent, that produces far more overhead.

HTTP may be very good if we use clients that violate standards and only send binary data there. As TCP packets can be ideally queued, redirected, and with proper HTTP headers even cached, combined, evaluated before recieving it, that might be of advanced speed. On the other hand we have the header for each request (not for each package Thank GOD for this!), that makes it a bit slower to handle.

But I am talking of lags in matters of milliseconds of delay, not processing time. When the first HTTPd-webserver has been released by NSCA, they could already process more requests than every average telnet server. HTTP is even better than p2p sharing tools, because these all need to supply their special headers. HTTP doesn’t

But streaming is still faster? yes, really faster… but consume more power.

We conclude, XML produces overhead, TCP is easier to handle, HTTP headers can improve the performance of proxies, and LL can use this to make everything possible at light-speed.

If you decided to really use XML, please supply SL proxies to compress data to clients

There are, however, serious upper limits to the architecture and those are going to require a commitment of real money to real high capacity data management tools –not MYSQL.

No one has commented on the fact that numbers of online users that would, only a short time ago, have crippled SL completely are now being tolerated quite well.. why has no one commented on that ?

See, not all NPIOF players can (or will) pay for their accounts, but not all of them are a “drain” on the system.

Maybe the “majority” who feel LL should ban all NPIOF players should look at the stats for who bought/sold and purchased L$.. and look at who actually *builds* all those things people spend their L$ on ! (nods to YY for his efforts..).