Page 2 of 2
Re: Looking back at performance
Posted: Wed Apr 10, 2019 3:41 pm
by Gangrenous
tyrbo wrote: Wed Apr 10, 2019 1:51 pm
Anyway, your load time issue may ultimately be a result of the server software you're running. It was for me. I suffered through long load times that came out of nowhere for quite a long time before by chance I loaded up MariaDB for one of my dev servers instead of MySQL.
Yeah, I cannot imagine that long of a load time. You may want to do some performance checks. That is insanely long zone times, never seen that even before I removed duplicate spawns. Seems like Antonica had like 20-30k in spawns before I did mass removal.
Re: Looking back at performance
Posted: Wed Apr 10, 2019 6:01 pm
by tyrbo
No need for performance checks. As I said in my previous post, the issue was completely alleviated after swapping to MariaDB.
I can only surmise it started when the DB client libraries were updated like, a year or so ago.
As for mass removals, yeah, we did that a long time ago as well.
I'm perfectly happy with Antonica and Commonlands starting up in 10 seconds with a new zone process.
Re: Looking back at performance
Posted: Wed Apr 10, 2019 6:08 pm
by Gangrenous
tyrbo wrote: Wed Apr 10, 2019 6:01 pm
No need for performance checks. As I said in my previous post, the issue was completely alleviated after swapping to MariaDB.
I can only surmise it started when the DB client libraries were updated like, a year or so ago.
As for mass removals, yeah, we did that a long time ago as well.
I'm perfectly happy with Antonica and Commonlands starting up in 10 seconds with a new zone process.
I was referring to EmemJr, even though I was quoting you.
Re: Looking back at performance
Posted: Wed Apr 10, 2019 7:01 pm
by tyrbo
Ah, sorry. Wasn't clear to me.
He's probably experiencing the same thing, but not too sure.
Re: Looking back at performance
Posted: Thu Apr 11, 2019 3:08 am
by Ememjr
i can attempt a switch to MarisDB, will my current My Sql DB's be compatible
Re: Looking back at performance
Posted: Thu Apr 11, 2019 5:15 am
by Gangrenous
Yep.
Re: Looking back at performance
Posted: Thu Apr 11, 2019 7:05 am
by Ememjr
i will assume it will have to be on another server, or can they coexist on same server
Re: Looking back at performance
Posted: Thu Apr 11, 2019 7:52 am
by Gangrenous
Ememjr wrote: Thu Apr 11, 2019 7:05 am
i will assume it will have to be on another server, or can they coexist on same server
I am not understanding? MariaDB is kind of the successor to MySQL in a way.
Re: Looking back at performance
Posted: Thu Apr 11, 2019 8:19 am
by Ememjr
do i hae to install it a=on another box or will they coexsit on the same server until i get mariadb up and running then i can uninstall mysql
Re: Looking back at performance
Posted: Thu Apr 11, 2019 9:32 am
by Gangrenous
That may be a question for someone else, my server is on Linux.
Re: Looking back at performance
Posted: Thu Apr 11, 2019 9:46 am
by tyrbo
MariaDB isn't a successor, but it's meant to be a drop-in alternative to MySQL. MySQL was purchased by Oracle, people were like "woah, not sure how we feel about that", and forked MySQL to create MariaDB, with the promise that MariaDB will always be open source.
Anyway, they should be interchangeable, but there's definitely something going on with slow loading when I've used MySQL with the emulator. I'm not sure if it's specific versions or not.
edit: In Linux at least, they share the same default folder structure (so /etc/mysql and other folders). It's a drop-in replacement, so I would _assume_ it can work with your existing stuff, but you certainly wouldn't want them running and touching the same database files at the same time. You'd also need to change the default port of 3306 to something else, since you can't bind both to the same port.
Just make a database backup before you do anything with mysqldump.
Re: Looking back at performance
Posted: Thu Apr 11, 2019 10:03 am
by Ememjr
its only 2'45 whn on local machine running in debugger, maybe 25 secs for antonica on my production server
Re: Looking back at performance
Posted: Thu Apr 11, 2019 10:04 am
by Ememjr
there are alot of vectors used in the emu, and i was reading vectors are tremendously slow in debug mode
Re: Looking back at performance
Posted: Fri Apr 12, 2019 8:30 am
by Gangrenous
I found a better way of doing this. There was a small performance hit but way less code and way more reliable. The issue was maintaining two list of spawns, it became cumbersome. Performance was a slight bit better the previous method but overall this is a better solution. Basically I just added a property to the spawn list called is_active. When the sweep is done to check the spawn_range and make the spawn map, I either set it to true or false. Then when the combat checks and movement check is done, it is only done for active spawns. This is cleaner and works great. I can set the rule and reload my rules and watch the spawns stop moving real time when I set a distance of something like 20.
Re: Looking back at performance
Posted: Sat Apr 13, 2019 6:50 pm
by Cynnar
You can run
MariaDB alongside MySQL if that is what you want to do.
MariaDB is a drop in place replacement for MySQL, but you can also install it alongside MySQL. (This can be useful, for example, if you want to migrate databases/applications one by one.)
I did run it along with MySQL when I wanted to swap over. Mostly so I could export my MySQL databases and then source them in to MariaDB without having any downtime for any of my databases, and to see if it was possible to do. I did have to change the port for MariaDB because MySQL was already uisng 3306, but I changed it when I had moved everything over and uninstalled MySQL.