prince
Veteran Member
cool
Posts: 435
| Likes: 969
|
Post by prince on Aug 15, 2019 22:28:03 GMT
you and your american players i'm just here chillin' in the land down under Pathetic australian |
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Aug 15, 2019 22:31:34 GMT
I'll give you a hint for free, loads of massive worlds = Minecraft servers running like shit. Can also be poorly tuned java instances on the host and that sort of thing as well, plenty of easy wins to make the server more reliable. Wouldn't it be smarter to create a cluster of servers to distribute the load? For instance, have multiple Digital Ocean droplets, host one server on each of them with certain resources/plugins allocated to them. Not only does this allow the server as a whole to stay up even if one resource server drops dead, but allows for great performance. Kinda, problem being unless you split flatlands and the main world into separate servers say, it's hard. We did it for CJFreedom V2 and it works fairly well as long as that's what players expect. I also worked with someone playing with the idea of synchronised changes and players cross-server with the players loaded on other servers. There are ways of doing it, and ways of doing it really nicely it's just not quick / easy. |
|
|
|
Post by Polaris Seltzeris on Aug 15, 2019 22:35:08 GMT
Wouldn't it be smarter to create a cluster of servers to distribute the load? For instance, have multiple Digital Ocean droplets, host one server on each of them with certain resources/plugins allocated to them. Not only does this allow the server as a whole to stay up even if one resource server drops dead, but allows for great performance. Kinda, problem being unless you split flatlands and the main world into separate servers say, it's hard. We did it for CJFreedom V2 and it works fairly well as long as that's what players expect. I also worked with someone playing with the idea of synchronised changes and players cross-server with the players loaded on other servers. There are ways of doing it, and ways of doing it really nicely it's just not quick / easy. That's the problem with the Minecraft server, it handles just as well as it did in 2010 despite it being a bloated piece of shit now. It's literally one daemon with no multithreading. Best thing that can be done is to try to use multiple daemons through a nice cluster and have one daemon manage one plugin, one daemon manage one world, one daemon manage player data, one daemon manage chunk operations, etc. Except you can't do that in a nice way because of how it's designed. But really, we should be able to at least fix the basic player-caused crashes. |
|
|
|
Post by Polaris Seltzeris on Aug 15, 2019 22:39:27 GMT
I'll give you a hint for free, loads of massive worlds = Minecraft servers running like shit. Can also be poorly tuned java instances on the host and that sort of thing as well, plenty of easy wins to make the server more reliable. The majority of crashes have been from exploits used to deliberately crash the server, or crash all players in a certain range of the exploit. But how many of those crashes can be avoided by having a less bloated server? |
|
|
|
Post by Polaris Seltzeris on Aug 15, 2019 22:48:07 GMT
But how many of those crashes can be avoided by having a less bloated server? I'm sure the number of worlds doesn't help performance, but the majority of crashes haven't been related to the number of worlds and would've happened regardless due to the nature of the exploits. But that's not how servers work. Think about the fly speed crash for instance, if you had one world running per server then that crash just simply wouldn't happen (although yes, we can put in a simple limit to prevent malicious usage as Windows suggested). The problem when you have all these things running on one server instance is that one server is processing several operations, and without proper multithreading as well, so it's just grandfathered in that you're going to have less performance and it's going to be more susceptible to basic exploits. If the server literally crashes because of a Java error caused by an exploit, that's one thing but we're talking about when the server locks up and throttles. |
|
kai
Veteran Member
if she dont play the craft she don't get the shaft
Posts: 1,022
| Likes: 1,374
|
Post by kai on Aug 15, 2019 23:19:14 GMT
I'm sure the number of worlds doesn't help performance, but the majority of crashes haven't been related to the number of worlds and would've happened regardless due to the nature of the exploits. But that's not how servers work. Think about the fly speed crash for instance, if you had one world running per server then that crash just simply wouldn't happen (although yes, we can put in a simple limit to prevent malicious usage as Windows suggested). The problem when you have all these things running on one server instance is that one server is processing several operations, and without proper multithreading as well, so it's just grandfathered in that you're going to have less performance and it's going to be more susceptible to basic exploits. If the server literally crashes because of a Java error caused by an exploit, that's one thing but we're talking about when the server locks up and throttles. but that would be taking the "easy way out" and a solution from "lazy developers", like you said in windows' thread about disabling spawn eggs. spawn eggs were essentially useless other than creating exploits since we have /spawnmob, but removing worlds that are actually used on the daily would be really redundant to increasing player amount. |
|
|
|
Post by Polaris Seltzeris on Aug 15, 2019 23:28:23 GMT
But that's not how servers work. Think about the fly speed crash for instance, if you had one world running per server then that crash just simply wouldn't happen (although yes, we can put in a simple limit to prevent malicious usage as Windows suggested). The problem when you have all these things running on one server instance is that one server is processing several operations, and without proper multithreading as well, so it's just grandfathered in that you're going to have less performance and it's going to be more susceptible to basic exploits. If the server literally crashes because of a Java error caused by an exploit, that's one thing but we're talking about when the server locks up and throttles. but that would be taking the "easy way out" and a solution from "lazy developers", like you said in windows' thread about disabling spawn eggs. spawn eggs were essentially useless other than creating exploits since we have /spawnmob, but removing worlds that are actually used on the daily would be really redundant to increasing player amount. I never called the developers lazy, but thanks. Windows provided a solution which would only hurt the people that are trying to exploit fly speed, and what happened instead is the exploit wasn't fixed and non-malicious usage was instead impacted. I support the solution which doesn't impact regular players. Players are also a hell lot more likely to know how to use a spawn egg than /spawnmob. I also at literally no point said that the solution is to remove the worlds, I said that the load could be distributed among multiple servers in a cluster system which would prevent lag and crashes, boost performance, and also make sure that the entire server doesn't come down because one world was fucked. |
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Aug 16, 2019 21:19:59 GMT
Kinda, problem being unless you split flatlands and the main world into separate servers say, it's hard. We did it for CJFreedom V2 and it works fairly well as long as that's what players expect. I also worked with someone playing with the idea of synchronised changes and players cross-server with the players loaded on other servers. There are ways of doing it, and ways of doing it really nicely it's just not quick / easy. That's the problem with the Minecraft server, it handles just as well as it did in 2010 despite it being a bloated piece of shit now. It's literally one daemon with no multithreading. Best thing that can be done is to try to use multiple daemons through a nice cluster and have one daemon manage one plugin, one daemon manage one world, one daemon manage player data, one daemon manage chunk operations, etc. Except you can't do that in a nice way because of how it's designed. But really, we should be able to at least fix the basic player-caused crashes. I *think* the server side can be multi-threaded now, from memory that's one of the main things Spigot did but that may have changed. The issue with that is while it a good idea, it's a significant amount of complex development that to be honest I'd be surprised if we have laying around on the server (Given I can't imagine anyone that skilled would be still sitting here when they could be making some good money as a dev IRL). And I agree, there's a massive amount of easy win's we seem to have just forgotten / ignored. |
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Aug 16, 2019 21:21:28 GMT
But how many of those crashes can be avoided by having a less bloated server? I'm sure the number of worlds doesn't help performance, but the majority of crashes haven't been related to the number of worlds and would've happened regardless due to the nature of the exploits. That tbh is even worse. These are all simple and quick wins... I had assumed we had already covered that sort of basic stuff and this was a technical challenge rather than anything else... |
|
StevenNL2000
Forum Admin 
Posts: 6,415
| Likes: 6,936
IGN: StevenNL2000
Timezone: UTC+01:00
Member is Staff. Need immediate assistance? Send a PM
|
Post by StevenNL2000 on Aug 16, 2019 22:28:30 GMT
That's the problem with the Minecraft server, it handles just as well as it did in 2010 despite it being a bloated piece of shit now. It's literally one daemon with no multithreading. Best thing that can be done is to try to use multiple daemons through a nice cluster and have one daemon manage one plugin, one daemon manage one world, one daemon manage player data, one daemon manage chunk operations, etc. Except you can't do that in a nice way because of how it's designed. But really, we should be able to at least fix the basic player-caused crashes. I *think* the server side can be multi-threaded now, from memory that's one of the main things Spigot did but that may have changed. Sorry, that was never a thing. The people who have worked on Bukkit and its forks explain that it's not a realistic goal because Minecraft was built from the ground up to rely on the tick chain having a very specific order (think "entity A always updates before entity B because it has a lower index in the internal list"). If you were to run everything in parallel, 99% of game mechanics would become inconsistent. The Spigot fork Paper we are using painstakingly made chunk loading asynchronous, but it took them 3 months to port it to 1.14, so you can figure for yourself how long it would take to do everything else. I'm sure the number of worlds doesn't help performance, but the majority of crashes haven't been related to the number of worlds and would've happened regardless due to the nature of the exploits. That tbh is even worse. These are all simple and quick wins... I had assumed we had already covered that sort of basic stuff and this was a technical challenge rather than anything else... Minecraft exploits are a moving target. If you want an unexploitable server, it will also be one where you can't place blocks or use items. |
|
Wild1145
Club 4000 Member
Inactive Player & Inactive Senior Admin
Posts: 10,414
| Likes: 9,680
|
Post by Wild1145 on Aug 17, 2019 12:32:53 GMT
Sorry, that was never a thing. The people who have worked on Bukkit and its forks explain that it's not a realistic goal because Minecraft was built from the ground up to rely on the tick chain having a very specific order (think "entity A always updates before entity B because it has a lower index in the internal list"). If you were to run everything in parallel, 99% of game mechanics would become inconsistent. The Spigot fork Paper we are using painstakingly made chunk loading asynchronous, but it took them 3 months to port it to 1.14, so you can figure for yourself how long it would take to do everything else. That sounds reasonable, as I say I thought Spigot was designed to be multi-threaded, but have clearly mistaken that with something else. Minecraft exploits are a moving target. If you want an unexploitable server, it will also be one where you can't place blocks or use items. Doesn't mean you can't be actively preventing them... Especially the really obvious stuff and from what people are saying here that sounds not to be the case. I'm only going off of what's been said in this thread, and what I can remember from when I was more active. |
|
|
|
Post by mychaeljkmax on Aug 17, 2019 15:46:05 GMT
With a server like Total Freedom, or any game server for that matter, you can always be sure to expect a fluctuation about the player base at different times of the year. However, while there are many players and admins who will be less active as a result of returning to school, it is summer vacation in different parts of the world for different players, so with a drop in activity in one time zone you can expect a spike in the other.
In either case, though, I would not worry about it too much.
|
|
- Achieved Aug 2nd, 2016
- Achieved Jul 6th, 2017
- Achieved Nov 15th, 2017
- Achieved Nov 2nd, 2018