Hi,
is it meaningfully, to split functions of the script in function-parts to make it quicker?

For example search.cgi with a own search.pl and search.cfg could be one function.
Second could be add_record.cgi with own add_record.pl and add_record.cfg.
Third could be modify.cgi with own modify.pl and modify.cfg.

Or could give this idea problems, if they all administrate one database at the same time?

I mean no because of flock, but wha do you mean?

The script could run much quicker because of sharing the work to do.

Tell me, what do you think.

Pit

I'll be interested to see the outcome. Links 2.0 has seperate Search.cgi, Modify.cgi, Admin.cgi etc.

Surely this would be faster?!

Cheers!
Ben
------------
http://www.travel-experiences.com

I have stripped down db.cgi and effectively created two additional cgi scripts, one for admin functions and another for author functions (as opposed to "regular" members). I have not yet benchmarked the db working with and without the stripped down db.cgi, and so cannot comment on whether it is marginally faster, but the one thing in favor of doing this is that it greatly simplifies editing the files, reducing one 90K monstrosity into several more manageable 20-40K files. I considered making DBMan even more modular, but then decided that I would eventually have to upgrade to the SQL version anyway as the DB grew to make these changes worthwhile.

You would not want to make separate .cfg files. The information in the .cfg file is needed by just about every routine that is done in DBMan.

This is a concept that is a little too complicated for me, right now. I would have to think about it a lot before I could give you any real answers.

JPD

OldMoney,

Could you give us an example of how you split the code? I can see that you would have moved certain sub routines to the new files, but how does the script know which file to reference? Do the url's have to change to reflect the new files? Eg admin.cgi?

Perhaps you could post an example or just an outline of the ideas you have used.

Cheers!
Ben
------------
http://www.travel-experiences.com

I have found that using the User-friendly html.pl and keeping all the formatting codes in a file called format.pl as JPDeni suggested greatly reduces the html.pl files.

With working with relational databases i also found that the section for

## Authentication ##

could be moved into a separate file I called multi.pl
I did leave in: sub html_unauth {

This greatly reduced the size of the html.pl files which used the same routines.

You would then add the following to your html.pl and db.cgi:

require $db_script_path . "/multi.pl";

Or it might work to just include the require statement in your .cfg files.

The specific sections I moved into multi.pl:

sub html_admin_display {
sub html_unauth {
sub html_signup_form {
sub html_signup_success {
sub html_change_password_form {
sub html_change_password_success {

When using a main format.pl file to hold all your main variables, it makes it much easier to be able to divide up your script to cut down on the file size.

Hope this helps :)

Hmmm... well, I've added so many new functions (and redefined old ones) that it's hard to know where to start to tell you what to move where. The basic concept though is that you do have to change the urls to reflect the new files, e.g.

/path/to/your/cgi-bin/db.cgi?db=default&uid=someone.12345678&view_records=1
as opposed to
/path/to/your/cgi-bin/db_admin.cgi?db=default&uid=someone.12345678&admin_display=1

I also moved much of the "utility" functions into a new common .pl file, like query, get_record, join_encode, etc, and then of course required the .pl. I would recommend of course first backing up everything, and then starting with an exact duplicate of db.cgi delete things to see what you can get away with. Experimentation is the key to making progress...

Cheers Guys!

I'm going to make a complete copy of my DB, move it to a new directory and play! If it works out I'll let you know!

LoisC, did you find much difference in the speed of your DB?

Cheers!
Ben
------------
http://www.travel-experiences.com

Cheers Guys!

I'm going to make a complete copy of my DB, move it to a new directory and play! If it works out I'll let you know!

LoisC, did you find much difference in the speed of your DB? If you are requiring files, does it load them even if not required? Or does it load-on-demand? Obviously I think it must do the latter, otherwise speed differences would be minimal

Cheers!
Ben
------------
http://www.travel-experiences.com

Benseb:

Couldn't really tell you about the speed difference as the site where I used that specific database just opened today.

I did it more for the size of the files and for easier editing. I like being able to open up different editors depending on the file size, as they each have different viewing features, etc.

I could be wrong, but I think it would only call the file if it needs the subs within it. In my case only one database (users) would need to access the authentication subs.

I think the size of your database is what's going to determine the speed more than anything else. Also using absolute paths rather than relative paths within your footers, etc. will slow things down.

I have broken the db.cgi into two files db_utils.pl and db.cgi.

And BTW: To see the difference in searching and processing forms in db.cgi versus broken db.cgi, use Benchmark.

Regards,

Eliot Lee

Hi all,

my idea is:

If I only copy the db.cgi, default.cfg and html.pl to the each function-files (add.cgi,add.cfg,add.pl...)(search.cgi,search.cfg,search.pl...), I can delete in these files not nessessary subroutines.
But that is only one Advantage and not the big one I look for.

The other is, and that is the big one, that if 30 people want to use one script at the same time, it will need mor time as if these 30 people use for example 3 or 4 files to do that work.

You know, one is using the "add-copy-files", other is using the "search-copy-files" other is using the "admin-copy-files" and so on.

Normaly all users must share one script! In this split-file-case, the can use 3 or 4 scripts to do the same work.

the only is, you have to link them to the new "subscripts" in your forms.

So your server has to do more work in the same time, but not the script themself.

Am I right or do I make a mistake in my idea?

Pit

Modular design is bandwidth and CPU friendly...So, you are on the right track with your ideas.

Regards,

Eliot Lee

Apart from splitting the script for performance reasons, would it be possible and meaningful to split html.pl for maintenance reasons? Like in one General and one Individual part.

I run several databases and seem to be likely to add more, and I want the same functionality in all, that is to use the mods I already have implemented. This is simple enough, but when I add new feature/mods I must do it in several html.pl -files (Each html.pl has of course different names).

So I just thought that the maintenance would be more simple if you could take out the subs from html.pl that explicitly use the data base fields (like html_record_form, html_record_long, html_search_options etc.) to a <database>_html.pl and keep the remaining general subs in html.pl. The individual <database>_html.pl would be set up in the .cfg file?

Wouldn't this simplify maintenance?