But will they fix the Log in's???

If this fix tommorow does not directly fix the log ins or addresses it, then whats the reason for the upgrade??????????????????????????????????????????

Haha, I was wondering the same thing.

its a backwards medifore, They'll fix it when everyone loses interest in logging into SL


!taerG si eip

Gotta love backwards medifores o.o pieee

It indirectly fixes it, but cutting down on the amount the DB server needs to deal with, which will free up servertime for logins.

-Adam

Breathing room while they figure out why thier projections didn't match reality. Or, if they know that, then this gives them time to change thier strategy. Any way you look at it, the patch beats just not doing anything about it, so I don't understand the original complaint.

As Philip pointed out in another thread. The slow logins are just the symptom of the real problem. Database load. We can't 'fix' logins until we get the database load down.

How do we go about doing that? Anything we can do to help out?

Empty your trash folder and trim your inventory if possible.

I am sure LL has some fix(es) in mind on their end as well.

I'd clean out my inventory if I could actually log in to access it. ;P

lol me too. although i seriously am going to empty all that useless crap, when I get on that is.

I can't get on because my inventory is full, and I can't clean my inventory because I can't get on

kidding, I know thats not the only reason, and my inv isn't even that big. Still needs a clean though.

Done.
If that would really help the database load, how about making it a MOTD?

If I'm understanding what I read the problem is email scripts, not inventories.

If I've got that right, then I'm very concerned that what we are seeing is a conflict between the needs of people who see SL as some sort of comercial 'game' and people who enjoy the other aspect of SL.

And it thats right...then it seem that the Lindens could make a simple choice right now to end the email problem and let us log on.

I must really be confused. Help me out. Someone explain how it is that the fun has gone out of SL. Is it too many people? Is it a reluctance to draw the line somewhere? Is it just the price we have to pay for someone's need for bigger numbers?

It's large inventories, and all the other excessive DB loads. A lot of fixes are going into a lot of area's with 1.6.5, which should give some breathing room for LL to implement some more radical architecture changes.

We didn't do a MOTD on reducing inventories because right now (while login load is high) frequent searching and deleting in inventories will temporarily increase load, which we don't want. Once login load drops we'll encourage folks to delete stuff, but until then it would be best if you would use inventory as little as possible.

Script email appears to be the highest load query, and will hopefully go to zero load with the design change tommorow morning. Behind that inventory queries are the worst, and we are trying to quickly move inventory to separate hardware.

I'm not busting out a magnifying glass to read any of that!

You might feel differently if you had systems that relied on email. Unfortunately, it is the ONLY way for two objects to talk to each other (unless they are in shouting range, which is not possible in many cases.) For example, there are some vendors out there that send an email to a central delivery script and that script delivers product to a user. Turning off email would result in people paying for things and getting nothing in return.

Technologically, this problem has two "prongs." Number one, email has to be polled for. Ideally it would raise an event instead of having to be pulled, then we wouldn't have to ask "Do I have email? Do I have email? Do I have email?" over and over ad infinitum. If you are running a chat relay that polls once a second, that's 86,400 queries a day. Number two, the other option is to use XML-RPC for inbound traffic - but inworld objects cannot send XML-RPC and even when you get a message over XML-RPC the whole thing blocks for three seconds. So if you are doing anything time-sensitive it sucks. (There are ways around that but using them is complicated.)

So people like me end up doing systems that have outbound traffic on email and inbound traffic either on email or over XML-RPC. Some people open an XML-RPC channel and poll it continuously in order to see if any messages are waiting, thus bypassing email for the most part. Nice if you have control over the machine and no one will terminate your process, but not feasible for many of us who are using shared application hosting.

The tools we have work sort of alright but could be a lot better. Here's how:

1. Create an email_received() or similar event and let us use that rather than repetitively polling for new mail. Keep the old llGetNextEmail() of course so that old stuff keeps working. This is already the way XML-RPC works.
   
   
   
2. Make XML-RPC bidirectional, so that objects can talk to other objects and to offworld applications. (This is already on the way.)
   
   
   
3. Give us a real XML-RPC implementation, one where we can actually create and query full XML-RPC structures. An integer and 250ish bytes of text is preferable to nothing at all, but the current scheme misses the point of using something as flexible as XML. We need tools to add, modify, and remove data structures within XML trees.
   
   
   
4. Build a robust infrastructure for us that will scale up going forward. Do what you want with email but XML-RPC calls should not block for more than half a second AT MOST. Once XML-RPC is actually bidirectional, it will not be necessary for offworld logic to sit there and poll a script 86,400 times a day. Throttle scripts that ARE doing that if you must, but a script that is only doing a few transactions per minute at most should not be delayed.