RE: [PHP] what PHP really needs
A database server by nature must assume that all data is equally mutable. An application developer, however, knows by design how fresh any one piece of data needs to be and can cache accordingly. E.g., don't hit the database for your site's navigational structure or news articles every single time, if these things don't change more than a few times per week. I have found SQL_CACHE to work ok ? -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
On Friday 23 January 2004 22:33, John W. Holmes wrote: From: Chris Boget [EMAIL PROTECTED] [snip] [/snip] Learn and use C++ Or sessions. Along with serialize() and deserialize(), all are your friends in this case. He's talking about the same set of data being available to all instances of PHP, though. I think they're called Application Variables. So if I set $instance=1 as an application variable, any other PHP script that runs can read that value. I imagine the same thing could be done with an object. Either that or I'm way off base. It does sound useful, but I see how it could be overused and abused. check pete M's mail in this list, sent at 25 NOV 2003. As written in that mail quote Another idea would ne to use an application variable.. This is like a Session variable but is site wide http://0x00.org/php/phpApplication/ regards Pete /quote -Stathis. PS: Whatever you need, there is a PHP solution for it. Never doubt about it:-) ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
-Original Message- From: Hamid Hossain [mailto:[EMAIL PROTECTED] As a ColdFusion Certified Developer I can say: You are right! In CF you can fire a sql statment and store its result in a variable which is not going to be removed from the server's memory after responding to the user. That variable will be available for sometime declared by you when you created the query. Perhaps you weren't aware that every modern database does the same thing (or can if you turn it on): the results of query sets are cached at the db server and are available if the same query is used without involving a file read. If any update changes any of the underlying result sets then the corresponding cache entry is invalidated and the momeory released for another cache entry. Let the db server handle query/cache consistency ... why put yet another server in the way that will have to be triggered by the underlying db to clear ITS cache? Mark C, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
Like Hamid Said, if the ColdFusion server has the query already in memory. It doesn't need to send traffic to another server to get the information again. Most systems I've worked on have the db and the web server on different areas of a firewall, so you're going through a lot of excess steps if you're hitting the db every time for something that won't change. Plus, you have a granular control on what is being cached. The sql server will only cache what it has room for. So if enough queries are run against it, the original query won't be cached anymore regardless. But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. Marlon (another certified cf developer) -Original Message- From: Mark Charette [mailto:[EMAIL PROTECTED] Sent: Saturday, January 24, 2004 9:35 AM To: [EMAIL PROTECTED] Subject: RE: [PHP] what PHP really needs -Original Message- From: Hamid Hossain [mailto:[EMAIL PROTECTED] As a ColdFusion Certified Developer I can say: You are right! In CF you can fire a sql statment and store its result in a variable which is not going to be removed from the server's memory after responding to the user. That variable will be available for sometime declared by you when you created the query. Perhaps you weren't aware that every modern database does the same thing (or can if you turn it on): the results of query sets are cached at the db server and are available if the same query is used without involving a file read. If any update changes any of the underlying result sets then the corresponding cache entry is invalidated and the momeory released for another cache entry. Let the db server handle query/cache consistency ... why put yet another server in the way that will have to be triggered by the underlying db to clear ITS cache? Mark C, -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Marlon Moyer wrote: Like Hamid Said, if the ColdFusion server has the query already in memory. It doesn't need to send traffic to another server to get the information again. Most systems I've worked on have the db and the web server on different areas of a firewall, so you're going through a lot of excess steps if you're hitting the db every time for something that won't change. The problem I have with this is where the database DOES change, and not on any set interval. I used to work at Insight, and our product database changed constantly, at any give moment to account for pricing changes, stock changes, specials, updates from places like TechData, etc. If I'm caching the results of my query, I miss those updates, and have a customer placing an order for a product at the wrong price, out of stock, etc. Now I can somewhat understand the use of this on a db that rarely changes, depending on how often rare is. Or in a case where the db is updated at a set time. Still, if rare is a time period of months, why have a db anyway? Static HTML would be faster than php, cold fussion, etc. And if the db is updated at a set time, what happens when I have to push a change out that is outside of the set time? Maybe it's just me, but I feel that the db is supposed to handle the dynamic data, not the web server. Plus, you have a granular control on what is being cached. The sql server will only cache what it has room for. So if enough queries are run against it, the original query won't be cached anymore regardless. But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. Marlon (another certified cf developer) -- By-Tor.com It's all about the Rush http://www.by-tor.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
On Sat, 24 Jan 2004, Marlon Moyer wrote: Like Hamid Said, if the ColdFusion server has the query already in memory. It doesn't need to send traffic to another server to get the information again. Most systems I've worked on have the db and the web server on different areas of a firewall, so you're going through a lot of excess steps if you're hitting the db every time for something that won't change. You missed the point. If you have to connect to a server anyway, whjat's the difference between going to a cached queryset on a CF server or going to a cached queryset on a db server? It's a wire transaction in any case. Plus, you have a granular control on what is being cached. The sql server will only cache what it has room for. So if enough queries are run against it, the original query won't be cached anymore regardless. And this won;t happen on the CF server when you run out of memory to cache a transaction? Yeah, right. Does CF have to query the db server to stay in sync? Of course it does. Now there's multiple transactions to coordinate synchronize. But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. That remains to be seen. Getting the data in an optimal way can be a non-trivial operation. -- Half the people know what they're talking about, and the other half are writing code. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Marlon Moyer wrote: But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. Again, if you're just talking about reading, how hard is it to just do this to save: $save_data = '?php $array = ' . var_export($array) . '; ?'; Now save that to a RAM disk and include() it whenever you need it recreated. You can do the same thing with objects, too. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
Like Hamid Said, if the ColdFusion server has the query already in memory. It doesn't need to send traffic to another server to get the information again. Most systems I've worked on have the db and the web server on different areas of a firewall, so you're going through a lot of excess steps if you're hitting the db every time for something that won't change. You missed the point. If you have to connect to a server anyway, whjat's the difference between going to a cached queryset on a CF server or going to a cached queryset on a db server? It's a wire transaction in any case. [Marlon Moyer] Because most CF servers are installed on the same web server, no wire is required between the web server and cf server. Plus, you have a granular control on what is being cached. The sql server will only cache what it has room for. So if enough queries are run against it, the original query won't be cached anymore regardless. And this won;t happen on the CF server when you run out of memory to cache a transaction? Yeah, right. [Marlon Moyer] You don't have much control over what a db server caches, but considering I can tell CF exactly what I want it to save the chances are less likely, but still possible, that it will flush from memory. It's the same with session variables. I could keep saving data in session variables until I ran out of memory also. Does CF have to query the db server to stay in sync? Of course it does. Now there's multiple transactions to coordinate synchronize. [Marlon Moyer] I'm not talking about queries that require constant refreshing. That would be a bad use of an application variable. What I'm talking about are queries that maybe refresh once or twice a day. I can schedule this easily. But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. That remains to be seen. Getting the data in an optimal way can be a non-trivial operation. -- Half the people know what they're talking about, and the other half are writing code. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
I don't have a problem with this method. It would be nice though to be able just set 1 application variable and be done with it. -Original Message- From: John W. Holmes Marlon Moyer wrote: But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation. Again, if you're just talking about reading, how hard is it to just do this to save: $save_data = '?php $array = ' . var_export($array) . '; ?'; Now save that to a RAM disk and include() it whenever you need it recreated. You can do the same thing with objects, too. [Marlon Moyer] This is something I wish CF had the ability to do. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals - www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
-Original Message- From: John Nichel [mailto:[EMAIL PROTECTED] The problem I have with this is where the database DOES change, and not on any set interval. I used to work at Insight, and our product database changed constantly, at any give moment to account for pricing changes, stock changes, specials, updates from places like TechData, etc. If I'm caching the results of my query, I miss those updates, and have a customer placing an order for a product at the wrong price, out of stock, etc. [Marlon Moyer] This isn't a situation that you would use a cached query. You would only use it when something doesn't change that often, or you have control of when it changes. Now I can somewhat understand the use of this on a db that rarely changes, depending on how often rare is. Or in a case where the db is updated at a set time. Still, if rare is a time period of months, why have a db anyway? Static HTML would be faster than php, cold fussion, etc. And if the db is updated at a set time, what happens when I have to push a change out that is outside of the set time? Maybe it's just me, but I feel that the db is supposed to handle the dynamic data, not the web server. [Marlon Moyer] My time frame is usually once or twice a day. I've set up admin pages that will refresh the queries on demand, or the pages themselves update the db and then refresh the query. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
f stock, etc. [Marlon Moyer] This isn't a situation that you would use a cached query. You would only use it when something doesn't change that often, or you have control of when it changes. Hell, I have stuff like that - it's called generate an include file with a cron job. Trivial. All my web pages include it. The variables are all set by an outside process. Re CF server Web server. It's on the wire (using sockets). You're going up down the stacks just as if you're using a wire except for the last 2 levels (ip above stacks are used). And only the smallest shops would consider having a web server and CF (or db) server on the same box. No scalability or easy recovery from failure. Heck, I run a tiny little ISP out of my basement, and have all major services segregated onto different machinery with 1000baseT private net between the different boxes (db search services, DNS resolvers, web servers, mail server, and backup array). -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
Let the db server handle query/cache consistency ... why put yet another server in the way that will have to be triggered by the underlying db to clear ITS cache? Very true, but tests I've done in the past with PostgreSQL and MySQL-driven PHP sites show that adding a simple static file cache (for data that changes rarely) can make a world of difference on a heavily-loaded site, trimming response times by 90% in some cases. A database server by nature must assume that all data is equally mutable. An application developer, however, knows by design how fresh any one piece of data needs to be and can cache accordingly. E.g., don't hit the database for your site's navigational structure or news articles every single time, if these things don't change more than a few times per week. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
--- Mark Charette [EMAIL PROTECTED] wrote: And only the smallest shops would consider having a web server and CF (or db) server on the same box. No scalability or easy recovery from failure. This is incorrect. The recommended Web architecture for ColdFusion is to have the Web server and the CF server on the same physical box and to have many of these nodes running on small servers. As for the ColdFusion versus PHP discussion, I'm not really interested. Chris = Chris Shiflett - http://shiflett.org/ PHP Security Handbook Coming mid-2004 HTTP Developer's Handbook http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
--- John W. Holmes [EMAIL PROTECTED] wrote: Marlon Moyer wrote: But I think the original question was about a tree that took a long time to create, and application variables would be a plus in this situation... Again, if you're just talking about reading, how hard is it to just do this to save: $save_data = '?php $array = ' . var_export($array) . '; ?'; Now save that to a RAM disk and include() it whenever you need it recreated. You can do the same thing with objects, too. Wow, the simplicity of logic at its best. :-) Nice one, John. Chris = Chris Shiflett - http://shiflett.org/ PHP Security Handbook Coming mid-2004 HTTP Developer's Handbook http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Chris Shiflett wrote: snip As for the ColdFusion versus PHP discussion, I'm not really interested. What about a Godzilla versus the Shrek dragon discussion? ;) -- By-Tor.com It's all about the Rush http://www.by-tor.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
[snip] [/snip] Learn and use C++ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
[snip] [/snip] Learn and use C++ Or sessions. Along with serialize() and deserialize(), all are your friends in this case. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
You can use shared memory too...only on *nix flavors though. -- Ray On Fri, 2004-01-23 at 12:42, PHP general wrote: There's 1 really important thing missing in PHP as I see it, and it's the ability to keep variables in memory for as long as the programmer choose. If this was possible there could be some truly great optimizations done. Some things are very slow to create but very fast to work with. I wrote a XML class a couple of days ago and while it's extremly quick to search and work with, sadly it's rendered pretty much useless since creating the tree which it uses isn't fast enough. I've heard there's a feature like this in Cold Fusion, which every Cold Fusion user seems to think of as the holy grail, and I would have to agree with them. One thing I've heard they use this for is to load an entire database into system memory. I don't know exactly how it's works but imagine having the whole database in system memory. When you change data you update it both in system memory and on the drive, but when you select (which is what you mostly do), you just query the mirror in system memory. So how cost effective could this be? 1GB of system memory is pretty much minimum on a decent server today. Assuming the site generates aprox 1 million bytes worth of data every day (storing images and other types of massive data in the tables would perhaps not be apropiate) the site could be up and runing for 1 thousand days. And if you just keep tables that gets queried a lot, but doesn't get altered often, you could most likely come up with a great compromise. I can't say for sure how much faster things would be but I'm guessing at several 1000% faster, however I might be way off. The only drawback I can see is that there might be multi threading issues, so if this would be implemented a new key word would probably have to be introduced to make data mutexed, or perhaps the other way around to avoid to many people scratching their heads. /Sebastian Karlsson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
On Fri, 2004-01-23 at 12:42, PHP general wrote: There's 1 really important thing missing in PHP as I see it, and it's the ability to keep variables in memory for as long as the programmer choose. If this was possible there could be some truly great optimizations done. Some things are very slow to create but very fast to work with. I wrote a XML class a couple of days ago and while it's extremly quick to search and work with, sadly it's rendered pretty much useless since creating the tree which it uses isn't fast enough. Sessions? I've heard there's a feature like this in Cold Fusion, which every Cold Fusion user seems to think of as the holy grail, and I would have to agree with them. Of course, Cold Fusion 'programmers' are only one step above Microsoft ASP/.NET 'programmers. One thing I've heard they use this for is to load an entire database into system memory. I don't know exactly how it's works but imagine having the whole database in system memory. When you change data you update it both in system memory and on the drive, but when you select (which is what you mostly do), you just query the mirror in system memory. Great if you're the only one hitting the db, and it's on the same machine. What happens when I have 15 webservers accessing the same database across 5 mirrored machines, and an update is made to one of my products? If I'm only reading from what was loaded up in memory, I miss the update. -- By-Tor.com It's all about the Rush http://www.by-tor.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
There's 1 really important thing missing in PHP as I see it, and it's the ability to keep variables in memory for as long as the programmer choose. If this was possible there could be some truly great optimizations done. Some things are very slow to create but very fast to work with. I wrote a XML class a couple of days ago and while it's extremly quick to search and work with, sadly it's rendered pretty much useless since creating the tree which it uses isn't fast enough. Sessions? Sessions or cache files stored on a mount point mapped to RAM, even. If you want to go that far. - michal migurski- contact info and pgp key: sf/cahttp://mike.teczno.com/contact.html -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
From: Chris Boget [EMAIL PROTECTED] [snip] [/snip] Learn and use C++ Or sessions. Along with serialize() and deserialize(), all are your friends in this case. He's talking about the same set of data being available to all instances of PHP, though. I think they're called Application Variables. So if I set $instance=1 as an application variable, any other PHP script that runs can read that value. I imagine the same thing could be done with an object. Either that or I'm way off base. It does sound useful, but I see how it could be overused and abused. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
-Original Message- From: PHP general Sent: Friday, January 23, 2004 1:43 PM To: [EMAIL PROTECTED] Subject: [PHP] what PHP really needs I've heard there's a feature like this in Cold Fusion, which every Cold Fusion user seems to think of as the holy grail, and I would have to agree with them. [Marlon Moyer] ColdFusion allows you to store variables in several different scopes including Session, Application, and Server. You already know session variables. Application variables only exist within a specified application and can have a timeout specified. Server variables can be accessed by all applications on that server. One thing I've heard they use this for is to load an entire database into system memory. I don't know exactly how it's works but imagine having the whole database in system memory. When you change data you update it both in system memory and on the drive, but when you select (which is what you mostly do), you just query the mirror in system memory. [Marlon Moyer] I've never seen anyone load an entire database into the application scope but it is common practice to load small queries that deal with the application into the application scope. For example, I have a calendar that allows you to choose only certain dates. These dates are in a table and can be modified 1 or 2 times a week. Instead of the application hitting the database everytime, I store the query in an application variable. The only drawback I can see is that there might be multi threading issues, so if this would be implemented a new key word would probably have to be introduced to make data mutexed, or perhaps the other way around to avoid to many people scratching their heads. [Marlon Moyer] You do have to account for race conditions, but I'd gladly deal with those and still have the convenience of application variables. /Sebastian Karlsson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
--- John W. Holmes [EMAIL PROTECTED] wrote: He's talking about the same set of data being available to all instances of PHP, though. I think they're called Application Variables. Yes, this is what he was talking about, which I think most people seem to have misunderstood to be something else. This type of question usually comes about because of the fundamental differences between ColdFusion and PHP. Specifically, I use PHP as an Apache moduke, so I'm using mod_php. I'm bound to Apache's behavior, since I'm just adding features to Apache. ColdFusion is a separate process, cfserver, and it talks to the Web server over a socket. While this does have drawbacks due to the added overhead, it also allows for a few extra features (application variables, ColdFusion Administrator, etc.). Still, for anyone who thinks application variables are great, search Google for PHP application variables, and you'll find a plethera of solutions that offer exactly that. Hope that helps. Chris = Chris Shiflett - http://shiflett.org/ PHP Security Handbook Coming mid-2004 HTTP Developer's Handbook http://httphandbook.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Hey, I'm not really sure and am possibly wa off base but...cant something like this also be done by using global for variables? Cheers, -Ryan On 1/23/2004 9:33:55 PM, John W. Holmes ([EMAIL PROTECTED]) wrote: From: Chris Boget [EMAIL PROTECTED] [snip] [/snip] Learn and use C++ Or sessions. Along with serialize() and deserialize(), all are your friends in this case. He's talking about the same set of data being available to all instances of PHP, though. I think they're called Application Variables. So if I set $instance=1 as an application variable, any other PHP script that runs can read that value. I imagine the same thing could be done with an object. Either that or I'm way off base. It does sound useful, but I see how it could be overused and abused. ---John Holmes... -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
I'm not really sure and am possibly wa off base but...cant something like this also be done by using global for variables? No, not really. That wouldn't be accessable by all users, which, as it turns out, is what the OP had asked for. Chris -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
John W. Holmes wrote: From: Chris Boget [EMAIL PROTECTED] [snip] [/snip] Learn and use C++ Or sessions. Along with serialize() and deserialize(), all are your friends in this case. He's talking about the same set of data being available to all instances of PHP, though. I think they're called Application Variables. So if I set $instance=1 as an application variable, any other PHP script that runs can read that value. I imagine the same thing could be done with an object. Either that or I'm way off base. It does sound useful, but I see how it could be overused and abused. ---John Holmes... Then you could use a serialized file in the filesystem that any app can read. For added speed, make a RAM-disk and store the file there. Slight overhead deserializing, but it's likely faster than recreating whatever it is (if it's large). -- paperCrane Justin Patrin -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Justin Patrin wrote: Then you could use a serialized file in the filesystem that any app can read. For added speed, make a RAM-disk and store the file there. Slight overhead deserializing, but it's likely faster than recreating whatever it is (if it's large). Then you've still got to worry about concurrency issues. Just reading the file isn't any good if you can't update the variables when appropriate. So that means the script needs to lock the file between reading, updating, and writing. Like Chris said, though, this has been discussed before and Google likely has some possible solutions. -- ---John Holmes... Amazon Wishlist: www.amazon.com/o/registry/3BEXC84AB3A5E/ php|architect: The Magazine for PHP Professionals www.phparch.com -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] what PHP really needs
Chris Boget wrote: I'm not really sure and am possibly wa off base but...cant something like this also be done by using global for variables? No, not really. That wouldn't be accessable by all users, which, as it turns out, is what the OP had asked for. Chris Like someone else mentioned using PHP's shared memory functions would get you close. I prefer to use something like Turck MMCache to cache the compiled php script rather than using shared memory. PHP not making variables accessible to all instances is a feature a lot of people depend on, very few PHP programmers seem to unset variables when they are done with them unfortunately If you are wanting to cache information consider serialize like others have said, there is very little PHP doesn't already do, if you are having a problem attack it from another angle because it is most likely you have not designed the best solution to the problem. It is always best to define the problem before deciding on a solution. Jason -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] what PHP really needs
As a ColdFusion Certified Developer I can say: You are right! In CF you can fire a sql statment and store its result in a variable which is not going to be removed from the server's memory after responding to the user. That variable will be available for sometime declared by you when you created the query. This is usefull, suppose you want to show the last 20 recoreds added to your site, you will fire the query once per hour! So, if your site visitors are 1000 per hour, your transaction to the actual db will be 1 time per hour not 1000 per hour. Sounds Greate! That also has a drawback, you have to be smart enough. You should use this feature only if your query is fixed and it should return some limited value. For example, you cannot store your search results because each and every visitor will use his own key words. Regards, Hamid Hossain Saudi Arabia Original Message Follows From: PHP general [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [PHP] what PHP really needs Date: Fri, 23 Jan 2004 20:42:59 +0100 There's 1 really important thing missing in PHP as I see it, and it's the ability to keep variables in memory for as long as the programmer choose. If this was possible there could be some truly great optimizations done. Some things are very slow to create but very fast to work with. I wrote a XML class a couple of days ago and while it's extremly quick to search and work with, sadly it's rendered pretty much useless since creating the tree which it uses isn't fast enough. I've heard there's a feature like this in Cold Fusion, which every Cold Fusion user seems to think of as the holy grail, and I would have to agree with them. One thing I've heard they use this for is to load an entire database into system memory. I don't know exactly how it's works but imagine having the whole database in system memory. When you change data you update it both in system memory and on the drive, but when you select (which is what you mostly do), you just query the mirror in system memory. So how cost effective could this be? 1GB of system memory is pretty much minimum on a decent server today. Assuming the site generates aprox 1 million bytes worth of data every day (storing images and other types of massive data in the tables would perhaps not be apropiate) the site could be up and runing for 1 thousand days. And if you just keep tables that gets queried a lot, but doesn't get altered often, you could most likely come up with a great compromise. I can't say for sure how much faster things would be but I'm guessing at several 1000% faster, however I might be way off. The only drawback I can see is that there might be multi threading issues, so if this would be implemented a new key word would probably have to be introduced to make data mutexed, or perhaps the other way around to avoid to many people scratching their heads. /Sebastian Karlsson -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php _ Add photos to your e-mail with MSN 8. Get 2 months FREE*. http://join.msn.com/?page=features/featuredemail -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
