Lawrence
12-10-2000, 07:51 PM
Let me explain.
I'm working on a new web project at the moment (not appropriate to go into it here), and am considering writing a custom database type program that's tailored to the project's needs. The database program would be a C executable. It would be persistent - holding the database in RAM and backing up on disk on a regular basis. Furthermore, it would use sockets to await commands from a perl script. The perl script is what users on their browser actually access, and obviously, the perl script may have several instances at any one time (only one ever instance of the database). The perl script would use sockets to send commands to the C database, which would complete the request and send data back to the perl program.
Why? Because a born and die perl script that has to read data from files, sort it out, link it together, query and return is far too inefficient - and the number of instances is proportional to the amount of RAM you're using (and wasting). The centralised database would mean X amount of RAM was used at any one time, and very little more. Not having to read in data all the time, of course, makes the program far more efficient and faster.
Granted - nothing new. I could probably use MySQL or something for the task. But the question is - do web hosts object to their clients having such continuously running programs (like the C database) on their server?
I'm working on a new web project at the moment (not appropriate to go into it here), and am considering writing a custom database type program that's tailored to the project's needs. The database program would be a C executable. It would be persistent - holding the database in RAM and backing up on disk on a regular basis. Furthermore, it would use sockets to await commands from a perl script. The perl script is what users on their browser actually access, and obviously, the perl script may have several instances at any one time (only one ever instance of the database). The perl script would use sockets to send commands to the C database, which would complete the request and send data back to the perl program.
Why? Because a born and die perl script that has to read data from files, sort it out, link it together, query and return is far too inefficient - and the number of instances is proportional to the amount of RAM you're using (and wasting). The centralised database would mean X amount of RAM was used at any one time, and very little more. Not having to read in data all the time, of course, makes the program far more efficient and faster.
Granted - nothing new. I could probably use MySQL or something for the task. But the question is - do web hosts object to their clients having such continuously running programs (like the C database) on their server?
