Topic: What was that SQL trick?  (Read 1157 times)

0 Members and 1 Guest are viewing this topic.

Praxis

  • Guest
What was that SQL trick?
« on: June 19, 2004, 10:25:02 pm »
I had my MySQL shut itself down while the server was running today, because too many users logged on.  Not a crash of the server, just mySQL being finicky.

(actually was funny, since the DB suddenly was disconnected everyone found themselves without prestige or ships and had panick attacks)

I remember that Castrin once, a long time ago on the DynaAdmins group, told me a trick to modify the config of MySQL to increase the maximum amount of connections it will allow.

What was that trick again? Anyone?
« Last Edit: December 31, 1969, 06:00:00 pm by Praxis »

CptCastrin

  • Guest
Re: What was that SQL trick?
« Reply #1 on: June 19, 2004, 11:00:27 pm »
set-variable   =   max_connections=n << note no space in the second '=' statement

where  n = the number of thread connections you need ... general this should be set to 500+ for a SFC3 server.

The setting is in my.ini (win32 mySQL) or my.cnf (Linux or win32 mySQL).

gl

   

Bonk

  • Guest
Re: What was that SQL trick?
« Reply #2 on: June 20, 2004, 07:28:02 am »
Isn't there just one connection to the db? That is the ODBC connector (to which the serverkit connects)? If the serverkit is opening a new connection to the db for every character logged on (or character action) then I think we have found the problem with the SQL kits? When I write an application that uses an SQL db I connect to it once only and perform all the necessary queries etc, then close the connection to the db when finished. One application - one connection, I can see no need to do it any other way.  One application creating 500 seperate connections to the db is just plain absurd - there is no need of it. Enable persistent connections to the db and connect once - disconnect when finished - simple.  500 seperate connections from one local app to do one job certainly cannot help things.  (back to lobbying for release of the kit source - one day we may be allowed to fix it if we beg hard enough?)  

Perhaps what is required is elimination of the ODBC connector driver and the kit should connect to MySQL directly?
« Last Edit: December 31, 1969, 06:00:00 pm by Bonk »

Praxis

  • Guest
What was that SQL trick?
« Reply #3 on: June 19, 2004, 10:25:02 pm »
I had my MySQL shut itself down while the server was running today, because too many users logged on.  Not a crash of the server, just mySQL being finicky.

(actually was funny, since the DB suddenly was disconnected everyone found themselves without prestige or ships and had panick attacks)

I remember that Castrin once, a long time ago on the DynaAdmins group, told me a trick to modify the config of MySQL to increase the maximum amount of connections it will allow.

What was that trick again? Anyone?
« Last Edit: December 31, 1969, 06:00:00 pm by Praxis »

CptCastrin

  • Guest
Re: What was that SQL trick?
« Reply #4 on: June 19, 2004, 11:00:27 pm »
set-variable   =   max_connections=n << note no space in the second '=' statement

where  n = the number of thread connections you need ... general this should be set to 500+ for a SFC3 server.

The setting is in my.ini (win32 mySQL) or my.cnf (Linux or win32 mySQL).

gl

   

Bonk

  • Guest
Re: What was that SQL trick?
« Reply #5 on: June 20, 2004, 07:28:02 am »
Isn't there just one connection to the db? That is the ODBC connector (to which the serverkit connects)? If the serverkit is opening a new connection to the db for every character logged on (or character action) then I think we have found the problem with the SQL kits? When I write an application that uses an SQL db I connect to it once only and perform all the necessary queries etc, then close the connection to the db when finished. One application - one connection, I can see no need to do it any other way.  One application creating 500 seperate connections to the db is just plain absurd - there is no need of it. Enable persistent connections to the db and connect once - disconnect when finished - simple.  500 seperate connections from one local app to do one job certainly cannot help things.  (back to lobbying for release of the kit source - one day we may be allowed to fix it if we beg hard enough?)  

Perhaps what is required is elimination of the ODBC connector driver and the kit should connect to MySQL directly?
« Last Edit: December 31, 1969, 06:00:00 pm by Bonk »