views:

107

answers:

2

Hi there,

I'm having somewhat theoretical question: I'm designing my own CMS/app-framework (as many PHP programmers on various levels did before... and always will) to either make production-ready solution or develop various modules/plugins that I'll use later.

Anyway, I'm thinking on gathering SQL connections from whole app and then run them on one place:

index.php:
<?php
  include ('latestposts.php');
  include ('sidebar.php');
?>

latestposts.php:
<?php
  function gather_data ($arg){ $sql= ""; }
  function draw ($data) {...}
?>

sidebar.php:
<?php
  function gather_data ($arg){ $sql= ""; }
  function draw ($data) {...}
?>

Now, while whole module system application is yet-to-be-figured, it's idea is already floating somewhere in my brain. However, I'm thinking, if I'm able to first load all gather_data functions, then run sql and then run draw functions - and if I'm able to reuse results!

If, in example, $sql is SELECT * FROM POSTS LIMIT 10 and $sql2 is SELECT * FROM POSTS LIMIT 5, is it possible to program PHP to see: "ah, it's the same SQL, I'll call it just once and reuse the first 5 rows"?

Or is it possible to add this behavior to some DRM?

However, as tags say, this is still just an idea in progress. If it proves to be easy to accomplish, then I will post more question how :)

So, basically: Is it possible, does it make sense? If both are yes, then... any ideas how?

+2  A: 

Don't get me wrong, that sounds like a plausible idea and you can probably get it running. But I wonder if it is really going to be beneficial. Will it cause a system to be faster? Give you more control? Make development easier?

I would just look into using (or building) a system using well practiced MVC style coding standards, build a good DB structure, and tweak the heck out of Apache (or use something like Lighttpd). You will have a lot more widespread acceptance of your code if you ever decide to make it open source, and if you ever need a hand with it another developer could step right in and pick up the keyboard.

Also, check out query caching in MySQL--you will see a similar (though not one-to-one) benefit from caching your query results server side with regard to your query example. Even better that is stored in server memory so PHP/MySQL overhead is dropped AND you don't have to code it.

All of that aside, I do think it is possible. =)

angryCodeMonkey
I have an application which has the potential to generate several similar requests. All database interaction is sequestered through a database object, and the object itself (silent to the rest of the application) has a very rudimentary caching system in place; basically, certain non-volatile functions check to see if they've been called before with the same parameters and, if so, return the result which is stored in an array. It takes less than a few hundredths of a second to execute, yet if the cache gets hit instead of the database it saves time at 1-2 orders of magnitude. Food for thought.
Dereleased
If you are seeing that type of return in some cases then it may be appropriate--there have been more than a few times that I have stored mysql query sets that remain static in gzipped flat files on the server for retrieval instead of instead of going through MySQL (things like language translations that don't change). My main concern there would be multiple user interacting causing your data to become irrelevant while you are using stagnant cache. But in the right situation it might make sense to do what you are talking about--by and large though will you gain enough to merit the trouble?
angryCodeMonkey
+1  A: 

Generally speaking, such a cache system can generate significant time savings, but at the cost of memory and complexity. The more results you want to keep, the more memory it will take; and there's no guarantee that your results will ever be used again, particularly the larger result sets.

Second, there are certain queries that should never be cached, or that should be run again even if they're in the cache. For the most part, only SELECT and SHOW queries can be cached effectively, but you need to worry about invalidating them when you modify the underlying data. Even in the same pageview, you might find yourself working around your own cache system on occasion.

Third, this kind of problem has already been solved several times. First, consider turning on the MySQL query cache. Most of the time, it will speed things up a bit without requiring any code changes on your end. However, it's a bit aggressive about invalidating entries, so you could gain some performance at a higher level.

If you need another level, consider memcached. You'll have to store and invalidate entries manually, but it can store results across page views (where you'll really find the performance benefit), and will let unused entries expire before running out of memory.

eswald