Topic: ***** STRESS TEST for SG6***** Was last night, test is over thx all

[KBFLordKrueg]

Since we do not have time to determine if the burps were caused by TS bandwidth use and/or forfeits we will be going flatfile. No OCI but just a standard webmap. No biggie, we can play with the new toys on The Forge when SGO6 is completed. (and get back to debugging the serverkit)

*SIGH*
So who has to do the ship assignments?  (And I was so looking forward to assigning someone a E3 for being stupid... )
That's a real bummer tho....was really hoping for a good SQL server....

[Bonk]

Ship assignments will be done with Dave's new flatfile editor while the server is down, by me I guess.

Patience grasshopper, we will have an SQL server soon (aside from The Forge) debug runs will resume when SGO6 is complete.

I'm putting in the new missions now, but do not have the new shiplist and map yet and will not have it for a few hours, so once the flatfile test goes up there will be seperate downloads for missions until I get the new shiplist. Once I have the new shiplist I can create the new insstaller and upload it over about two hours.

[FPF-Tobin Dax]

We were running some forfeits around 1am eastern as it was requested, that's why Dizzy asked us to stop after we delivered a few.

[Bonk]

Yes, forfeits will often crash the server whether it is running on SQL or the flatfile. We are addressing indirectly related code in the debug development version of the kit. Ultimately I would like to disable the ability to forfeit as fixing it properly would involve re-writing much of the serverkit code.

[Lepton]

One or two burps on an SQL server and we are ready to bag it???  Flatfile servers have burps, ne c'est pas?  Are we getting a little ahead of ourselves here?

[Dizzy]

I'd like to try it again with the fixed shiplist where take out the long character names and parentheses. We just pile on and see what happens.

[FPF-DieHard]

Lets go live with it and see what happens.   The forfeits were intentional and will not be done to that degree on a production server.

No guts, no glory

[Dfly]

We were running some forfeits around 1am eastern as it was requested, that's why Dizzy asked us to stop after we delivered a few.

after you logged off and Dizzy had asked that forfeits be stopped, there were none that I saw for at least 1 hour later.  However, somewhere around 2-3 am EST there was 1 player who did multiple forfeits(at least that I noticed.  This was right around the time it burped again, and after that there was only Warp and myself online.  We both ran a mission or 2 then logged off for the night.

[Dizzy]

forfeits cause the server CPU to SPIKE. Causes crashes. Flatfile works the same way. We should probably try flatfile with a buncha peeps and forfeit a few missions and keep an eye on the server CPU process to see if it spikes. May not be sql at all... Maybe that the processor CPU cant handle it.

[Bonk]

As mentioned above. It does not matter whether the server is run on SQL or not, forfeits saturate CPU use and will eventually cause the server to crash. It may be amplified by using SQL due to the additional cpu overhead of MySQL but the effect holds for the flatfile as well. I know this to be true.

The flatfile test server is up and running. Do not bother forfeiting, I already know exactly what it does to the server in any configuration. The forfeit penalty will remain at 1000 PP to discourage forfeits.

Webmap is here: http://www.dynaverse.net/webmap_sgo6_ff/

Updated missions required here: http://www3.telus.net/NuclearWessels/sfc/downloads/NWPack.exe

The new SGO6 installer will not be posted until approximately 2 hours after I have received the new shiplist.

[762_XC]

Are we abandoning SQL then?

[Bonk]

For SGO6, yes. Ship assignments will be done with Dave's flatfile editor on db cleaning maintenance cycles.

The Forge will continue to run on SQL after SGO6 is done as there is no motivation for people to forfeit missions on it.

Testing of the debug development version of the serverkit will also resume after SGO6 is complete. We are committed to get the serverkit working well on MySQL.

[Lepton]

This was precisely as I feared, and now SQL is withdrawn for almost no reason whatsoever.  Was this a mere gambit to get an SQL stress test?  If so, time for some honest brokers to come forth and pony up the truth?

I have no understanding of what is transpiring here.  All the OCI hype and one problem to the public's mind and SQL is out the window?  What am I missing here?

[Bonk]

This was precisely as I feared, and now SQL is withdrawn for almost no reason whatsoever.  Was this a mere gambit to get an SQL stress test?  If so, time for some honest brokers to come forth and pony up the truth?

I have no understanding of what is transpiring here.  All the OCI hype and one problem to the public's mind and SQL is out the window?  What am I missing here?

No, the debug MySQL tests are run in a totally different (stock) configuration running a debug build from within the VC++ IDE. I have collected no debug data from the SGO6 test runs. It would be pointless, it is not running on stock files. A modded server cannot be used as a baseline.

I do not try and fool people and object to the insinuation. (like I would be that dumb to debug a heavily modded server...  )

Nobody will show up for MySQL debug tests because they are on stock files (and absolutely must be) but we press on.

The OCI was developed for The Forge which chugs along just fine. It is also to give people an idea of what is possible with running the kit on MySQL and hopefully provide some motivation to show up for stock debug test runs.

People are going to forfeit missions on a "serious" server no matter what. Forfetis max out the cpu to 100% for seconds at a time leaving no cpu left for MySQL to do its work, this snowballs and the server crashes.

SQL is not out the window, as mentioned above The Forge will continue to run on MySQL and tests of the kit on stock files in debug mode will continue to be run. We are committed to getting it to work well. Once it is done I would like to disable the ability to forfeit, or just replace the code with a function that does nothing, then move on the PvP DV shifts (which will work on the flatfile as well).

[Riskyllama]

perhaps its not the sql server causing all of these problems? perhaps its the cable causing issues? Seeing as usually when the cable is on the fritz, which seems to be a common problem around server launch times in retrospect, there always seem to be a lot of problems.

[Hexx]

As mentioned above. It does not matter whether the server is run on SQL or not, forfeits saturate CPU use and will eventually cause the server to crash. It may be amplified by using SQL due to the additional cpu overhead of MySQL but the effect holds for the flatfile as well. I know this to be true.

The flatfile test server is up and running. Do not bother forfeiting, I already know exactly what it does to the server in any configuration. The forfeit penalty will remain at 1000 PP to discourage forfeits.

Webmap is here: http://www.dynaverse.net/webmap_sgo6_ff/

Updated missions required here: http://www3.telus.net/NuclearWessels/sfc/downloads/NWPack.exe

The new SGO6 installer will not be posted until approximately 2 hours after I have received the new shiplist.

Unfortunate.

However ~ If I may be so bold~ If yuo want to discourage all forefeits make it a PENALTY. Cheap ships and high paying missions
(as well as 50K of course on the test) make 1k a drop in the bucket.
Make it 10K and I think you'd get alot fewer.

[Dizzy]

Ghosted players forfeit. Its a game engine problem...

Fast computers can handle forfeits. We dont have a fast server computer to handle them... DH could, but he has heat problems during the day. His computer catches fire.

I still want to try SQL... I think Im being backed into the flatfile corner tho...

[Bonk]

However ~ If I may be so bold~ If yuo want to discourage all forefeits make it a PENALTY. Cheap ships and high paying missions
(as well as 50K of course on the test) make 1k a drop in the bucket.
Make it 10K and I think you'd get alot fewer.

I was considering that, but I have not tested what happens if the forfeit penalty is greater than a players PP... will it go negative? Will it crash the server? This is unknown. If I knew that the serverkit would handle it properly I would the forfeit penalty to 1000000, but now is not the time for me to go digging through the serverkit code to find out if the math and code will handle that properly. Though we could test it and find out. But I still need the new shiplist and map and we are already past launch time...

[Dizzy]

U have the new shiplist ck ur email...

Ill get u the map fairly soon... Can you make terrain edits on the map using flatfile?

[Bonk]

Ghosted players forfeit. Its a game engine problem...

Fast computers can handle forfeits. We dont have a fast server computer to handle them... DH could, but he has heat problems during the day. His computer catches fire.

I still want to try SQL... I think Im being backed into the flatfile corner tho...

Ghosted players: bandwidth issue (and software firewalls)

Forfeits: will still max out a quad Xeon 2.4 GHz machine. (I have observed it occur on the UAW server hosted on such a box).

I would like to run on SQL too but I have already reconfigured for the flatfile and we are running late and I do not trust that people will not forfeit when convenient, knowing it will crash the server... (too many opponents on? forfeit a few times and crash the server... too easy an exploit.)

Let me think about it while I wait for the new shplist and map and over the two hours it will take to upload the new installer).