Preserved Topic: PHP-driven database Hard copy/archive question (Page 1 of 1)

Since I started working on an events database, I have started seeing more and more great uses for my PHP/MySQL database, including but not limited too automatically generated text link menus and the top and bottoms of pages.

The problem is that I'm hesitant to add PHP parsing to every single document on our websites, because it seems like a bit of processing overkill just to avoid updating menus on several pages every once in a while. So I want to know if there's any way to have PHP check the database for a flag indicating that a menu has been updated, whereupon it would generate a new static copy of the page, and reset the flag.

Basically it gets to the deeper issue of PHP saving a static copy of a document... is there a convenient mechanism to do something like this?

I do not think that the process of making a static page would be a good idea. No matter what, you would need to check the database. Because of this, it is just as faster to grab the data and place it in the document dynamically that to check the page and if it is different rewrite the page. The other problem in the recreation of the page is that you would have to work with locking the database when a check occures because 2 concurent requests to a page that was not updated would result in double the amount of work, and time.

Writing a page takes a lot of time compared to simply grabbing data and placing it into the page.

-mage-

Writing your menus to static HTML files can save some CPU cycles and here's my suggestion how to do it... You probably have an admin-like script that you use to add/remove menu items, right? Well, when you use that script, besides adding data to db it should also create those static HTML files (which you're going to include in your pages) at the same time.

Hmmm, good point. So the most efficient way would be to generate text files with the menus at the time of modification, then just insert the text. This would require a lot of text files (since I want each page to have it's own link disabled and the text bold), but I could put them in a sub-directory to keep them out of the way.

Hmmm, slick concept, but this begs the question: Are PHP includes as efficient as regular SSI?

Wow, this actually calls into doubt my whole method of serving the events from my database. Now I'm thinking none of the actual user pages should do any database processing. All the files should be generated when database changes are made. Since changes are only made every 2 weeks or so that would be MUCH more efficient than having every page constantly querying the database and building pages.

Shit, my decision to use PHP instead of Perl is seeming less and less important. thanks fer da input.

<edit> BTW, i wrote this response before seeing Max's </edit>

[This message has been edited by jiblet (edited 03-06-2001).]

If your pages are going to be updated every two weeks, then I see no reason to use PHP. Even if you create static HTML files, including them using PHP will take some CPU time, because everything else from that page (HTML code) has to be echoed, so using SSI might be more efficient. Also, there's another option, you can write a perl script which will be called from crontab and will generate complete HTML pages with everything included (something like pre-processor).

Wait, explain to me how including with PHP requires 'everything else to be echoed' while SSI doesn't. Both methods require the entire file to be parsed before serving it, but I'm assuming you mean PHP has some overhead here due to the fact that it has more possibilities. I can't imagine it would be much slower, but it probably doesn't matter since our server has never had to handle more than 1000 hits a day.

As for your 2nd comment. You are right, there is nothing here I couldn't accomplish with Perl, but the reason I am using PHP is not to serve up static pages, it's mainly for the on-line admintool. Having a perl script on crontab is not necessary because the database will only be modified through the admintool. Granted I could use Perl for the admintool, but PHP is so much easier because of the complexity of the admintool, and the variety of tables that will be outputed. I suppose I will lose some efficiency by using PHP rather than Perl, but since all the processing will be done at the time of modification it's not a big deal. Of course the main reason is that I already started learning PHP and have a PHP book (not to mention it's a lot closer to other languages I know like Java and C).


[This message has been edited by jiblet (edited 03-08-2001).]

In PHP pages, everything that is not inside <? blah ?> is converted internally to <? echo "HTML code goes here" ?>, so if your pages are not very dynamic (i.e. you have a lot ot HTML code that is outside <? ?> ), you shouldn't use PHP...

So would it be better to use an <!--#exec to call a perl script to handle whatever rather than to use PHP?

I currently am using PHP inside of two files. The first one grabs information from a database for display purposes, and the second grabs info for display along with incremementing a number on a specific entry view.

Would perl be a better solution? or is PHP fine in the way it is handled?

-mage-

Max is the expert. But here's my take. If it works and you are not having server slow-downs then this is fine. If you need more speed then making the switch to perl scripts will increase performance. If perl isn't fast enough then use java servlets. If java is too slow then use C scripts. If C is too slow then program it in assembly.

The point is that PHP should work great for what you want to do, but there's lots of room for improvement if you run into performance problems.

As Jiblet said, if your server can handle all requests you'll be fine (for now)...

Also, regarding speed of perl - by using mod_perl you can achieve speeds like those from Apache modules written in C!

I'd be interested in knowing how it compares to Java servlets in terms of speed... I suppose it would depend on the application.

Take a look at http://perl.apache.org/ for more information.