Quote:Bluemage wrote:As near as I can tell, the principle reasons this has gotten as bad as it has for them, is that the guy who owns the domain is completely incommunicado, and the guy that owns the server doesn't care (and probably won't even notice if it actually does fall over), and the only other guy who has basically superuser and physical access to the server itself (rather than just admin access to the forum software) is reluctant to do much because it's not actually his box. Unless one of those can be changed, they aren't getting more storage, nor is anything going to get deleted to provide a fix.Quote:robkelk wrote:Every cloud storage/data server solution I've worked with at my current job (100Mb/sec fiber connection) has had some pretty serious lag, compared to when we keep the data on our local network. Admittedly, the ones I've had the most hands-on experience with have been Microsoft's recent offerings, so that might just be a M$ thing, but that's what I've consistently observed.Quote:Bluemage wrote:
Local storage is probably the best option- it just has a long implementation lead time.
From what I know of servers and hosting (not as much as a full admin, but I have hands-on experience) you're best off having your storage all in the same place- the same site as your server, as tightly linked to the server as possible. Having your storage in the server itself is best, followed by external drive racks with dedicated connections. SATA external is third, followed by non-dedicated Ethernet connection or USB, depending on which USB standard and the local Ethernet load.
Using a remote system for your data storage is possible, but your software has to be written for it, and you're going to eat lag three ways- data request to storage, data received from storage, and data out to client. Not optimal, speed-wise- not to mention the reliability issues cloud anything tends to have! It's good enough for data backups at the current start of the art/'net, I've found, but not for active use- especially for a site with the kind of load SB gets.
This does not match with my knowledge of external storage. (Except for the part about storage over USB being bad - but how many servers even have USB ports?)
There's no reason software has to be written to specifically use external storage - just configure the external storage as a virtual drive, and it's presented to the software exactly the same way as a local drive. Yes, this requires root/admin rights on the server.
Data lag is trivial unless your connection is running slower than T1 speeds - and even home DSL connections run faster than T1 speeds nowadays. SB isn't connected to the Internet via dial-up, is it?
Local storage is tied to the physical server. This makes app portability difficult.
(EDIT: SATA? Really? Why choose so slow a disk? FC is the way to go.)
On a theoretical level, I don't see how it can't be. Depending on how your storage system
works, you're talking about going from A(client)->B(server)->A to
A->B->C(cloud storage)->B->A or A->B->C->A.
That's upping time spent in transmission (as well as signal processing)
by 1/3 to 2/3. Add to that that each hop in that model is actually more
like 10-20 different servers, and you're looking at a lot of waste.
Now multiply that by a few hundred (since each transmission takes up
capacity that might've been used to send the next) to get a ballpark for
SB's userbase (I figure they might, might peak near a thousand at once), and you definitely get nontrivial lag for most users.
Also, yes, you can just map it to a drive letter and use it that way- I was totally off-base about that part. I suspect that there might be purpose-built software that'd be more efficient about it, but that would work.
Either way, we can at least agree that SB's server isn't moving at (heh) sufficient velocity, and needs to be upgraded.
--
"You know how parents tell you everything's going to fine, but you know they're lying to make you feel better? Everything's going to be fine." - The Doctor