Yes, as Sindy says, its not the servers that are the issue. The problem is data transmission. They are sending thousands bytes of data for what prims are in view, plus thousands more for what textures are in use, and more for weather, and other effects, and scripts, and... There is only a few things that can "fix" lag:
1. Get people to stop customizing characters (not going to happen), since one of them can have huge numbers of prims on them.
2. Replace the mesh for the character, so you don't have to "mod" so much of it with prims.
3. Replace bitmap textures with procedural (where possible), this has the effect of letting the graphics hardware generate how something "looks" from much smaller amounts of data, but... I am not sure how good the shaders really are in 3D cards for this, or how easy they are to make. The 3D app I play with sometimes this wouldn't be hard, but it doesn't use the graphics card at all for its 3D, since it calculates surfaces by math, not based on meshes.
Hmm. Let me explain that better. For a pure math system, which cards don't support, if you want to draw a sphere it goes from the camera to the sphere, determines if it "hit" based on the physical equation for a sphere, then colors it. In a mesh system, which CG cards use, you take the sphere, break it up into roughly 64 "pieces", each angled to "look" like its part of a real sphere. This is way you can place a different "texture" on each "surface" that makes up your sphere. It is efficient for how the card works, but **not** efficient for storage, transmission, etc. SL "cheats" by using preset shapes, which don't need to be sent, then only sending info on how you resized it, rotated it, etc. Sculpies are another cheat, taking a "map" and moving each "surface" to a new place, based on the map, before showing it. Its costly, since it means sending... a texture. Its also unavoidable.
Pure math systems use heightfields, which only work on 2 dimensions, or isosurfaces. The former works like the terrains you can upload to SL, though they can be used to make any surface, including ones with holes, so long as it can be done in two dimensions. The other one, isosurfaces, is... lets just say you don't know what "lag" is. The math needed to make one, even to approximate such a surface, makes everything else look minor. Adding one to a project can take someone that would take 3 minutes to generate (its a photo-real program) and instead make it take 3 days, or even weeks.
4. As I recently posted a suggestion about, replace distant object's textures with quick colors. Basically, instead of seeing rock, you see something "rock colored" in the far distance. Think of it like what you sometimes see with characters when you first come in, where everyone is the right shape, more or less, but gray, then imagine if instead you got an "approximate" color for them instead. This since the large texture isn't "sent" until they got closer, or you did to them, or to a building, vehicle, etc., half the "data" needed by the client only gets sent as needed, not all at once. You could have a farther visual distance, but slightly smaller range of "detailed" distance, and still not lag *near* as badly as you would if you where loading 100% of all the textures needed for everything over that distance.
5. Find some voodoo ritual or star trek device that can "compress" everything down to 20% the bandwidth needed. lol
Frankly, I doubt #5 is particularly practical, so...
