You are here:
  1. Home
  2. Blog
  3. Interwebs
  4. tutorialtastic CMS

tutorialtastic CMS

 |  Interwebs

I’ve been working on tutorialtastic over the past two days because creating the page, writing the page, uploading the page, etc can get incredibly tedious — in fact it puts me off publishing tutorials in the first place (some of you see this as a good thing, you can shut up :p).

Anyway, the scripting stuff that controls this (main) site connects to the MySQL database at the start of the configuration file and therefore theoretically connects to the database on every page (because the config file is included on every page) even when a connection is not needed (80% of my pages). Although this site is never going to get to the point where it’s exceeding its available resources (rock on site5.com) I do think that if I make my code more efficient it’ll benefit me anyway: if nothing else but to educate me further.

So.. instead of just sticking a ton of code on every page where I want something pulling from the database I’ve put the appropriate code into various functions (fetch_updates(), fetch_categories() etc). This way, the code is only on one page so repeated stuff can just be called with one line instead of 30+ each time. Also, I’m using mysql_close(); at the end of the function when the hard work is done, although as I’m not using persistant connections I don’t know if this is of any benefit…?

What I’m after is a yes/no from anyone as to whether or not I’m on the right track in terms of increasing efficiency and perhaps some suggestions from any geek-geniuses too. :)

Jem Turner jem@jemjabella.co.uk +44(0)7521056376

14 comments so far

  1. Katy said:

    all my cms stuff runs off functions rather than code directly on the page. It’s so much easier in terms of keeping stuff updated too – change one file rather than 6 etc etc. Plus I can use the same function to do slightly different things with arguements and stuff. Dunno about mysql_close though, I don’t think it’s generally used that much. I could be wrong though.

  2. Amelie said:

    I’ve taken to doing the whole mysql_close() thing as well, but apparently it doesn’t make any difference if you’re not using mysql_pconnect() anyway since the database connection is closed at the end of script execution anyway. According to “PHP and MySQL for Dynamic Websites” by L. Ullman, which I’m currently reading, there’s no benefit in doing what you’re doing with the functions, because it uses more memory and system resources getting all your user-created functions together than querying MySQL for no reason. Hence, Ullman suggests you stick to using custom functions only when “absolutely necessary”. There ya go, hope that helped. :)

  3. Amelie said:

    Oh yes, and connecting and then reconnecting to MySQL wastes resouces as well – if you have 3 database queries for which you open a new connection each time, things can get a little bit heavy server-side. If I were you I’d just stick with the “pointless” connections… Either that or include the connection script only on pages that require it; paste all the MySQL stuff in a new file and include it in pages you know will need a query. *Consults book* That’s what M. Zandstra recommends in “Teach yourself PHP in 24 hours!!!!!1”. I’m still in exam mode, supporting all my arguments with books O____o oh well, never mind. More info for you.

  4. Jem said:

    That’s what I thought @ mysql_pconnect, but I was wondering if there were any potentially fractional savings by closing it straight away instead of letting it deal with it itself. Still unsure on that. The whole custom functions thing is for my own convenience really: I don’t see the point in having the same piece of code across 50 or so pages when it can be written once and just called when needed. I would say that a function is more “economical” than lots pages of repeated code any day..

  5. Amelie said:

    Well, none of the books I have address it, but I would say there’s not a lot of point in closing a connection as soon as it’s been dealt with unless you’re going to connect to a different database afterwards. I’m also unsure about it, but I add it to the end of my scripts just in case. It’s good practice, according to my books. As for functions, I completely agree – I use them for things that are repeated 239535382 times, but I don’t think in terms of MySQL connection that it’s necessary to use functions for that since it already has some; I think defining a function just to connect to MySQL is likely to use up any resources you might have freed using mysql_close(). Meh, just my opinion – do whatever you think is best. Maybe you could run a few tests on your local server and see how it fares resource-wise first?

  6. Jem said:

    Oh, you misunderstand me.. I’m not using custom functions simply to connect to the database, that’d be pointless. :P Although some of the functions do have database queries in, there’s more to ’em than that.

  7. Elea said:

    Someday I’ll be able to sit down and learn PHP fully, and then move on to mySQL. And then eventually I’ll understand all the things you’re blogging about and be able to lend some useful coding advice. =p

  8. Jim said:

    Why don’t you just use a database class, this way whenever you *need* to query/update, etc., you can just initialize a new object and do the work. Your execution times can’t really be that low or bothersome, can they? mysql_pconnect() doesn’t close when you use mysql_close(), so it doesn’t matter if you use it or not. Personally, I don’t use mysql_pconnect. If you use it improperly, you can cause apache to make so many threads waiting for connections that you end up slowing everything down or having MySQL refuse additional connections.

  9. Jem said:

    I know mysql_close() doesn’t work with mysql_pconnect() – I’m not using mysql_pconnect(), I was wondering what the benefits were of closing after a normal mysql_connect() (if any). I’m looking into writing a database connection/blabla class but it’s not something I’ve done before so it’s taking time :P

Follow on Instagram