I am fairly new to web programming, I have mainly used java to create desktop applications in the past.
I'm trying to figure out how to create persistent objects in php. Maybe persistent isn't the right word, I don't want the object to be unique to each client, like i would get by serializing it in a session variable. I want the object to be created on the server and have that same object be accessible at all times. The object would query the database and store some data. This way, each page load, the php code would get that data from the same persistent object rather than having to query the database each time.
I am currently using the singleton pattern for object creation because my initial understanding was that it would allow me to accomplish what i want. Part of the object is an array, and when i execute a php page that adds a value to the array, and access that value on the same page, its fine. However when i add a value to the array and then load another page that accesses the value, the array is back to being empty.
Is this possible? Am i overreacting in thinking that querying the database so much is bad? There will at times be as many as 20 users requesting data during any one second, and i feel like thats ridiculous to query the db each time.
Thanks
PHP does not have the concept of persistence as Java does: the JVM allows for Java applications to persist in memory between HTTP requests; the webserver forks a new PHP process every time a new HTTP request is served so an object's static variables will not persist data for you between requests.
Use a database to store persistent data. Web programming focuses on concurrency, so you shouldn't worry about database queries - 20 a second is few. If you reach the limits of your database you have the options to add a caching layer or "scale out" hardware by adding read-only slaves.
Usually you get your persistence by using the database. If that's a bottleneck you start caching data, for example in memcached or maybe a local file with a serialized array on your webserver.
Though it may not be the prettiest solution, but you can use SESSIONS for this matter.
class SomeObject{
public function __costructor{
$_SESSION['object'] = serialize($this);
}
}
and on another page, you can call the object simply with:
$object = unserialize($_SESSION['object']);
Though ofcourse this approach seems the easiest. It should come with utmost precaution:
Know that sessions depending on the traffic of your server should not be too large in size as many users concurrently ask for each of these sessions. Scale the size at your own discretion.
always serialize and unserialize as sessions not done so will misbehave.
What ever sails your boat. Do so at your own mindful analyzation. goodluck
Data persistence in Web programming is done thru the use of cookies/sessions and passing cookie/session variables across Web page calls. Theoretically, any kind of data can be stored in these variables - but for most practical purposes, only the more important data (look at them more like tokens) needed to identify/reconstruct the needed objects (with or without a database) are transferred to and from server and browser.
I'd advise you take a good look at memcached. When you're talking server load and performance capabilities, a useful metric is often pages/second. If you have a dedicated server and unoptimized but very intensive stuff going on, you may only be able to serve 5 pages/second. Utilizing data caching is a great way to increase that 3 to 10 fold. However, it's always a tradeoff as far as how stale the data can get. You will really need to test your site to properly understand (quantify) other possible performance-limiting factors such as other connections per page (images, css, etc), file i/o, other network activity, and last but not least the actual
It is possible to store objects in the current session. Now just create a base class which is able to store and recreate the object itself. Any derived object will then also be persistent.
You might want to read here : persistent base class and example
As far as i know the session is stored in RAM and thus should be faster than serialize the objects to disk to achieve persistence.
Stop using singleton and use dependency injection.
Best way is to use DataMapper (http://www.martinfowler.com/eaaCatalog/dataMapper.html) and attach it to an object by means of dynamic properties. Let the data mapper handle persistence.
$CS = new CookieStorage();
$SS = new SessionStorage();
$FS = new FileStorage('config/object.db');
$DM = new ObjectDataMapper($FS);
$O = new Object($DM);
$Object->DynamicProperty = 1;
Now DynamicProperty will automatically persist and will automatically be loaded from file object.db. And the class definition:
class Object
{
public function __construct(MapperInstance $Storage = NULL)
{
$this->setMapper($Storage?: new ObjectDataMapper(new FileStorage('config/object.db')));
}
public function __get($name)
{
$this->_Mapper->getProperty($name);
}
public function __isset($name)
{
$this->_Mapper->isProperty($name);
}
public function __set($name, $value)
{
$this->Mapper->setProperty($name, $value);
}
}
Related
I want to install a game on my site. The interaction takes a lot of jobs, mainly about moving the game's options to my site's admin option control pannel. To avoid the interaction job, I'm thinking to make a Class to store the options, and call the calss by Global.
Class Game_Vars{
var ...;
... ...;
}
Global $game_options;
if ( !isset( $game_options ) ) $game_options = new Game_vars();
By this way, the options won't be stored in database, and the Class.php will be loaded everytime when the game script is running. There are nearly 70 options, is this too heavy for performence?
It depends on how static the data is, which tells you how easy is must be to change the data. If the data never changes and does not need an interface to change it, then there is nothing wrong with using a class and storing your data in memory. Otherwise, use a database to better manage the data (but fetch the data once from the database using a design pattern such as a Singleton or a single static variable).
You will not run into any memory / hardware performance / efficiency issues when storing 70 data members of a class into memory on any semi-modern server. Especially since (as Pastor Bones points out) that regardless of which option you choose (database or file), all of the options will be loaded into memory at some point.
Sometimes file access is faster than mySQL for heavier sites. If your options are read-only, and you will have a huge number of concurrent users (concurrent connections), it might be better to use a file to store your options instead of the mySQL table.
The problem with mySQL is not the amount of data (relatively) but the number of connections.
I am writing a web application in an object oriented design. This application would be interacting with the database pretty often. A few regular operations are verifying a user's ACL permissions for the function/method requested, performing certain functions etc. In a nutshell, the database would be used a lot. So my question here is, if I do develop my application using OOP, and declare class level variables which would be used to set the input coming in, and if there is any parallel or concurrent request coming in from another user, would the input data be changed??
Would I have to do something separate to make sure that the application is multi-threaded and the input coming in be not changed until the process isn't finished??
ex:
class myProces{
var $input1;
var $input2;
function process1($ip1, $ip2){
$this->input1 = $ip1;
$this->input2 = $ip2;
$this->getDataDB();
}
function getDataDB(){
//do some database activity with the class level variables;
// I would pass the values in the class level variables;
$query = "select column from table where col1 = $this->input1 and col2= $this->input2";
mysql_query($query);
return something;
}
}
Now if I have two users hitting my application at the same time, and make a call to the functions in this class
user1:
$obj = new myProces();
$obj->process1(1,2);
user2:
$obj = new myProces();
$obj->process1(5,6);
Now if I do have class level variables, would they have changed values when concurrent requests come in?? Would PHP doing any kind of handling for multi threading? I am not sure if Apache can act as a message queue, where requests can be queued.
Can anybody explain if OOP for web applications with heavy number of users is good or if any kind of multithreading has to be done by developers??
A couple of things:
This has nothing to do with OOP.
PHP doesn't support user threads
Each request will be using its own memory, so you don't have to worry about concurrent usage updating variables behind your back.
However, you do have to take care when dealing with data from a database. User 1 may read something, then User 2 may read the same thing and update it before User 1 finishes. Then when User 1 updates it, he may be accidentally overwriting something User 2 did.
These sorts of things can be handled with transactions, locks, etc. Again, it has nothing to do with OOP or multithreading.
First: try to learn about PDO (unless that VAR before the variables, means that you're using PHP4).
Second: As konforce and Grossman said, each user gets differents instances of PHP.
Third: This problem may occur in Java projects (and others), that uses static objects or static methods. Don't worry with this in PHP.
There is no need to worry about mixing things up on the PHP side, but when you come up with a need to update or insert data, having several users being able to modify the same subset of data will lead you into unwanted consequences. Such as inserting duplicate rows or modifying the same row. Thus, you need to use SQL commands such as locking tables or rows.
This isn't a problem you have to worry about. Each connection to your web server spawns a totally separate instance of the PHP interpreter, with totally separate memory and resource handles. No objects in one will be affected by the other, no database connections in one will be affected by the other. Your class properties in one process are not ever modified by a request in another process.
Many of the top sites on the web run on Apache and PHP, with hundreds of concurrent request happening simultaneously all day long, and they do not have to write any special code to handle it.
Is there difference between caching PHP objects on disk rather than not? If cached, objects would only be created once for ALL the site visitors, and if not, they will be created once for every visitor. Is there a performance difference for this or would I be wasting time doing this?
Basically, when it comes down to it, the main question is:
Multiple objects in memory, PER user (each user has his own set of instantiated objects)
VS
Single objects in cached in file for all users (all users use the same objects, for example, same error handler class, same template handler class, and same database handle class)
To use these objects, each PHP script would have to deserialize them anyway. So it's definitely not for the sake of saving memory that you'd cache them on disk -- it won't save memory.
The reason to cache these objects is when it's too expensive to create the object. For an ordinary PHP object, this is not the case. But if the object represents the result of an costly database query, or information fetched from a remote web service, for instance, it could be beneficial to cache it locally.
Disk-based cache isn't necessarily a big win. If you're using PHP and concerned about performance, you must be running apps in an opcode-caching environment like APC or Zend Platform. These tools also provide caching you can use to save PHP objects in your application. Memcached is also a popular solution for a fast memory cache for application data.
Also keep in mind not all PHP objects can be serialized, so saving them in a cache, whether disk-based or in-memory, isn't possible for all data. Basically, if the object contains a reference to a PHP resource, you probably can't serialize it.
Is there difference between caching PHP objects on disk rather than not?
As with all performance tweaking, you should measure what you're doing instead of just blindly performing some voodoo rituals that you don't fully understand.
When you save an object in $_SESSION, PHP will capture the objects state and generate a file from it (serialization). Upon the next request, PHP will then create a new object and re-populate it with this state. This process is much more expensive than just creating the object, since PHP will have to make disk I/O and then parse the serialized data. This has to happen both on read and write.
In general, PHP is designed as a shared-nothing architecture. This has its pros and its cons, but trying to somehow sidestep it, is usually not a very good idea.
Unfortunately there is not right answer for this. The same solution for the same website on the same server can provide better performance or a lot worse. It really depends on too many factors (application, software, hardware, configuration, server load, etc).
The points to remember are:
- the slowest part of a server is the hard drive.
- object creation is WAY better than disk access.
=> Stay as far as possible from the HD and cache data in RAM if possible.
If you do not have performance issue, I would advice to do... nothing.
If you have performance issue: benchmark, benchmark, benchmark. (The only real way to find a better solution).
Interesting video on that topic: YouTube Scalability
I think you would be wasting time, unless the data is static and complex to generate.
Say you had an object representing an ACL (Access Control List) stating which user levels have permissions for certain resources.
Populating this ACL might take considerable time, especially if data comes from a database. The cached ACL could be instantiated much quicker.
I have used caching SQL query results, and time-intensive calculation results and have had impressive results. right now I'm working on an application that fetches more than 200 database records (which have a a lot of SQL functions and calculation in them) from a table with more than 200,000 records, calculate results from the fetched data, for each request. I use Zend_Cache component of Zend Framework to cache the calculated results, so next time I do not need to:
connect to database
wait for database server to find my records, calculation my sql functions, return results
fetch at least 200 (could even rich 1000) records into memory
step over all these data and calculate what I want from them
I just do:
call for Zend_Cache::load() method, that will do some file reading.
that will save me at least 4-5 seconds on each request (very inaccurate, I did not profile it actually. but the performance gain is quite visible)
Can be useful in certain cases, but comes with careful study of implications and after other kind of performance improvements (like DB queries, data structure, algorithms, etc.).
The query you cache should be constant (and limited in number) and the data, pretty static. To be effective (and worth it), your hard disk access needs to be far quicker than your DB query for that data.
I once used that by serializing cached objects in files, on relatively static content on a home page taking 200+ hits/s with a heavily loaded single-instance DB, with unavoidable queries (at my level). Gained about 40% performance on that home page.
Code -when developing that from scratch- is very quick and straightforward, with pile_put/get_contents and un/serialize. You can name your file after, say, the md5 checksum of your query.
Having the objects cached in memory is usually better then on the disk:
http://code.google.com/p/php-object-cache/
However, benchmark for yourself and compare the results. Thats they only you can know for sure.
Is there difference between caching PHP objects on disk rather than not? If cached, objects would only be created once for ALL the site visitors, and if not, they will be created once for every visitor. Is there a performance difference for this or would I be wasting time doing this? Thank you :)
The performance comes down to subsequent use so even if your object is cached once and used by all ... or cached once per visitor ... it is the subsequent use that counts. If your cached object is used 10,000,000 times a day then you will save.
If the cached object is used once or not at all, the gain is negligible.
It's like this:
File is way faster then Database.
Memory is way faster then files (when not swapping disk space).
So cache to memory what you need the most, and try and think when you need to make the effort to cache to file.
Remember: premature optimisation usually isn't the best thing to do.
You'll have to take in account that dynamic content must be cached whenever it changes. But, to static content, it's much more faster to use cached content, especially in database schemas, configurations, and that kind of thing.
Assuming that they are large objects, and especially if they are being built based on data pulled from a database, caching is a good idea. For some testing I did with a particular instance, it was quicker to build an object, write it to a file, and load from the file, than to go to the DB every time.
However: there are better ways than writing to a file. You would probably be better off storing the object in memory with memcached or APC, and don't forget that you may have issues with locks on the file is several people are hitting the site at once.
Caching objects on disk will give you the additional overhead of a disk write whenever there is a cache miss, whereas on a cache hit you will be able to save the step of instantiating the object.
If construction of the object is enough of a burden that saving it sometimes will more than outweighs the additional burden of a disk write, then go ahead and cache on disk.
I'd be curious, however, to know more about why instantiating your objects is so costly that you would want to do this.
#Aiden Bell
Errm. Depends on the object. If one instance can be shared then you save storage ... but it depends if the object is altered by the user. You will be reading/writing the object creating a bottle-neck. Without more information, you will have to lookup the theory here. – Aiden Bell 11 mins ago
--
These instances don't have data that can be altered by the user, however, they would contain data that would be used by users throughout the site.
Basically, when it comes down to it, the main question is:
Multiple objects in memory, PER user (each user has his own set of instantiated objects)
VS
Single objects in cached in file for all users (all users use the same objects, for example, same error handler class, same template handler class, and same database handle class)
--
Hi, anyone else have any ideas?
I am programming in PHP mysql.
I have recently got into OOP programming.
So I need to serialize my objects and store them to SESSIONS. However I think the huge sessions are slowing down refreshing and loading of my webpages.
Is there an alternative approach (than serializing deserializing) so that I can still share my objects from webpage to webpage and improve loading time.
Thanks
Rahul
You should first analyze what the actual bottleneck is. Is it really the object serialization/deserialization?
If so, ask yourself, if all the objects need to be present on every request or if they can be reconstructed on demand. Then you could just store the key values to reconstruct those objects instead of the whole objects.
But if you need all those objects though, use more performant storage location than the default (files in the file system), maybe the memory (memcache).
Are all the objects you store necessary from page load to page load? If not then you need to keep those objects out of the session and only reconstruct them on the pages that you need them.
Every object you store in the session will get serialized and unserialized on every page load regardless if you actually need it. So you'll want to keep that to a minimum.
Another option is store only what you need to reconstruct the object in the session and not the entire object. For instance you can store a database id in the session and reconstruct the objects from the database when you need them.
As a rule of thumb you should try to limit your Session-size to 4KB or less (independent on what programming language you use). If your data get's bigger than that, you should start using Tables in a Database (like MySQL/PostgreSQL/...) to persist the data.
Example: Store a draft for a Blog Article
In the Session (with all it's images etc) vs
In the Article-DB-Table (where a flag draft=1).
Believe me, it's more convenient if you choose the DB (and you don't have to hassle with serialization).