On a hunch... I would guess that your DB server is the bottleneck. If you've already coded in C, you're not going to get much faster than that (certainly not an interpreted language like perl, php or JAVA)
Consider (if possible) ditching the DB server altogether and going with some other type of shared storage. Also, look through your C code and consider optimizing it.
I've actually been working on a game that's similar to what you describe, using php as the UI, MySQL as the data server and C for the event processing routines. The major bottleneck is the MySQL server, and I've been toying with writing some sort of daemon to serve out the data to the other programs to replace MySQL. SQL is very fast and it's great (the flexibility and rapid development can't be beat) but it's just not fast enough for a game like that under heavy load.
Developing your own data engine will be time consuming, but if you MUST have the speed, that's the only way you'll get it.
Unless, of course, you just buy tremendiously powerful servers. Try moving the DB server onto it's own machine with REALLY FAST raid drives and tons of RAM. That might speed things up enough.
I've been doing this for about 6 months now. Here is some advice:
The ODBC drivers are buggy, but they are stable enough for production use (honestly). It's imperative that you match the correct driver with the correct version of windows. We've found that some versions work on W95C and but not on B. Really weird, but that's M$ for you.
We've only used Access for simple databases, but we have a huge database written in Paradox running through the Boreland Data Engine and then through the MySQL ODBC driver connected to a FreeBSD box running MySQL. It works great. Personally I'm really happy with the interface.
One last note. DO NOT use Access for databases that are accessed by more than a few people at a time unless you have _some_ sort of SQL server on the back end. The native concurrency stuff in Access doesn't work worth a hoot when you've got a lot of users. You end up with corrupted.mdb files every other day.
Personally, I recommend the Access->ODBC->MySQL setup. You can't beat the price on the server end!
Slashdot Mirror
On a hunch ... I would guess that your DB server is the bottleneck. If you've already coded in C, you're not going to get much faster than that (certainly not an interpreted language like perl, php or JAVA)
Consider (if possible) ditching the DB server altogether and going with some other type of shared storage. Also, look through your C code and consider optimizing it.
I've actually been working on a game that's similar to what you describe, using php as the UI, MySQL as the data server and C for the event processing routines. The major bottleneck is the MySQL server, and I've been toying with writing some sort of daemon to serve out the data to the other programs to replace MySQL. SQL is very fast and it's great (the flexibility and rapid development can't be beat) but it's just not fast enough for a game like that under heavy load.
Developing your own data engine will be time consuming, but if you MUST have the speed, that's the only way you'll get it.
Unless, of course, you just buy tremendiously powerful servers. Try moving the DB server onto it's own machine with REALLY FAST raid drives and tons of RAM. That might speed things up enough.
I've been doing this for about 6 months now. Here is some advice: The ODBC drivers are buggy, but they are stable enough for production use (honestly). It's imperative that you match the correct driver with the correct version of windows. We've found that some versions work on W95C and but not on B. Really weird, but that's M$ for you. We've only used Access for simple databases, but we have a huge database written in Paradox running through the Boreland Data Engine and then through the MySQL ODBC driver connected to a FreeBSD box running MySQL. It works great. Personally I'm really happy with the interface. One last note. DO NOT use Access for databases that are accessed by more than a few people at a time unless you have _some_ sort of SQL server on the back end. The native concurrency stuff in Access doesn't work worth a hoot when you've got a lot of users. You end up with corrupted .mdb files every other day.
Personally, I recommend the Access->ODBC->MySQL setup. You can't beat the price on the server end!