Matthew
Caldari
BloodStar Technologies
   |
Posted - 2006.09.04 11:52:00 -
[1]
 Originally by: Gretchen Dawntreader
bookmark should not be something able to lag the server anyhow.
Unless they hired some idiot to design them, all a bookmark consists of is a set of 3 decimal numbers, system identifier and a text string.
EVE has got to be handling millions of times that every second for every physical object in every system in eve and its position, icon, model, velocity, stats, shield/armor/hull levels, flags, states, player skills, physics model, transversal velocity to be displayed on every player's overview who is in range...
OMG the immensity of the data handled by this game every time you warp to a station with a dozen players, 6 turrets, 20 npc ships and etc should absolutely DWARF the 5 pieces of data needed for a bookmark.
X.
Y.
Z.
systemid.
$string.
That's all it should take. Do I know? Am I guessing? of course I am. But think about it. How much freaking data should it take to store and label a static coordinate in space....
NOT MUCH.
From what I gather, there are probably two elements to BM's in the database: The BM table, and the Item table. BM's in your People&Places probably aren't a huge problem, as they'd only appear in the BM table. It's BM's as Items that are likely to generate the problem, because they will have linked entries in the BM and Item tables. Copying BM's requires the creation of BM's as Items, hence requires the creation of lots of new linked table entries. That's where I suspect it starts to get ugly.
That's also why a hangar full of BM's takes much longer to load than a hangar full of normal items. When a normal item loads, it would load the TypeID, and the game can fill in the item name based on the locally cached info on that TypeID. When it loads the BM, it has to refer to the BM table to extract the $string description of the BM. Otherwise, every BM in your hangar would just be called "Bookmark". Incidentally, this is the same sort of thing that means that differentiating between BPC's and BPO's in the hanger is not feasible (it would be a reference to the BP table for the "IsCopy" property in that case). I suspect constant hangar refreshes during the copy process also causes a significant amount of load.
The other consideration is, yes, a BM is only a small amount of data. But people are rarely using just one. If they were, there wouldn't be a problem. The problem comes because BM's are being thrown around on the scale of thousands per player. Just look at valar's post. Assuming round numbers of 900k between 1200 and 2000 hours, gives you 112500 BM's copied per hour, 1875 per minute, 31 per second. And that's an average. If that was spread evenly over the whole cluster and over time, then it may have coped. But you're going to get peaks in time and location. Location especially is likely to concentrate around hub systems like Jita, which are already under significant load.
Of course, that is just as much speculation as your comments. What we know for certain is that copying BM's does cause an issue. Could that issue be solved by better coding? Probably, to some extent. But I'm personally doubtful it could be made scalable to the extent required. You also have to ask if it's sensible to engage in such a rewrite of the BM code, when you're planning on changing the whole nature of BM's anyway.
To those saying "Don't tell me not to copy, fix your servers": Do you honestly expect them to be able to put out a solution immediately? Just click their fingers and new nodes appear, new code comes online? Yes, a more long-term solution is required, but you can't whistle up long-term solutions overnight. If your boat springs a leak, sure you'll want to ask questions of the construction and maintenance of the boat. But that won't change the reality of that moment - you either start bailing, or you sink. The boat isn't going to listen to you saying "Don't tell me to bail, stop leaking".
-------
There is no magic Wand of Fixing, and it is not powered by forum whines. |