I am working on a project that uses PHP to create an 'complex' object with lots of references to other objects linking back to their parent objects etc...
The object structure is then serialized by the Zend AMF module and sent over to the flex application.
The problem is that serialization takes a lot of time (+10sec).
My question is thus: can anybody give me tips on how the serialization works and in what way I may be able to optimize the object structure in order to make serialization run faster?
Switching to JSON will help a great deal with this, as it allows easier caching.
APC will also help, just for the opcode-cache part, not for storing objects in memory.
How big is this object exactly? Could it be worth it not sending the entire thing? If you're just dealing with recordsets, you might be able to fix it in the frontend by only downloading only what the user can see, or will see in the near future.
The default serializer will iterate through every property, if a property is an object it will then iterate through each of those objects and their properties until it's done.
Since your object is complex, there's lots of crunching going on and many levels of objects that are being serialized.
As a point of optimization you may wish to look into implementing the serializable interface on your objects and serializing the minimal amount of information you require to be serialized and sent over the wire to your Flex app.
http://php.net/manual/en/class.serializable.php
When doing AMF serialization, or any serialization for that matter, it is usually better to work with smaller pieces of data if performance is a concern. By doing that you can work with individual objects as true ActionScript objects instead of just data placeholders. Smaller data when doing any type of RPC is usually better. You could use JSON instead, but then you'd loose the tight data binding that you get from using AMF. So try working with smaller packets of data using multiple HTTP requests.
Related
I was wondering what would be the best way to store JSON/XML responses. I'm currently building an application that supports heavily on the SoundCloud API to fetch songs/playlists etc.
Here are some ideas I've come up with.
Storing the results in a Relational Database and then using PHP to convert them to classes to make easy use of them throughout my application.
Doing the above, only this time using my framework's built-in ORM.
Using a Document-Oriented Database. (ie. MongoDB, couchDB, ...)
Storing the JSON responses in a cache. (using my framework's cache classes)
Can anyone care to shed some light on some of the advantages/disadvantages of using any of these methods?
Which one do you prefer?
If you have a solid schema, that you wont think it will change, you might want to use relational database. You will need to parse the json and make objects out of the JSON response and using your framework you can persist it to database.
If you think your schema will change use NoSQL.
It also depends what will you do with this data. Are you going to search the nodes within JSON?
You can also do a object to mongo mapping, you can either parse the JSON and store it as an object or you can store the JSON the way it is.
Nice thing about NOSQL is that they support JSON pretty well in which they use BSON (Binary JSON).
In terms of cache, IME, it should be used only for lookups, and actually, you cant search the cache. It s just for getting objects faster than going to database and getting it.
Take a look at this:
http://www.mongodb.org/display/DOCS/Inserting#Inserting-JSON
If you can tolerate hosting your music and playlist data on Google's AppEngine, Ubud-db can be something for you: https://bitbucket.org/f94os/ubud-db/wiki
Ubud-db is a document store on AppEngine with a REST-JSON API. Spring/Jackson maps from JSON to a Map, and then Ubud's service maps from the Map to Entity, persisted by the Datastore.
The REST-JSON API makes it easy to integrate with a website using AJAX to access and display dynamic data.
If I need keep the data for longer than a cache provider, I would store them in a database as-is and then just json_decode them when I retrieve them from the DB. If it's just temporary storage, cache is a great idea, still leaving it encoded as json to reduce the size.
I'm new to OOP using PHP and the idea seems a little pointless in some ways. In non-webbased languages the object lives through-out the life of the program (from execution to exit). In this situation it make perfect sense because you build the class then initialize it at run-time where you can access it frequently as needed there after. However with web programming since the execution of an application might happen in many stages (page loads) the life of the object could end up being only a small portion of the time an application is being run. So it seems to me that the only option to keep objects alive during the course of the application's usage would be to store that object after initialization in a session variable. Is this common practice or are there other means by which to utilize the power of OOP in PHP more effectively?
PHP's website has an article that deals specifically with this: Serializing objects - objects in sessions. There's absolutely nothing wrong with serialize objects in your session but as this article suggests:
It is strongly recommended that if an
application serializes objects, for
use later in the application, that the
application include the class
definition for that object throughout
the application. Not doing so might
result in an object being unserialized
without a class definition...
It can still be very useful to manage objects with short, time-limited lifespans. Perhaps you want to communicate with two different kinds of database servers -- having objects that know how to build queries for those database servers can be very convenient. You, the programmer, get to interact with them in the same way, but behind the scenes one might use a unix domain socket to talk with a local PostgreSQL and the other might use a TCP connection from a session pool to talk with an Oracle instance.
Object-oriented programming exist to provide encapsulation and abstraction. Both are useful, even if the objects involved are created, live, and die, in .5 seconds.
With PHP you cannot keep an object alive, so you cannot store it in the session to gain performance. PHP will always serialize the object when writing to the session and deserialize it reading from the session.
To answer your question, yes it's very common to store an object in a session, but not for performance reasons. Storing and reading from the session are quiet fast, so i would only look for optimizations there, if you are sure this is a bottleneck.
Somethings to make sure you do if you take this approach is make sure your garbage collection is thoroughly working. Depending on what the object does it may store as quite a large record in which case you will be taking up quite a bit of disk/database storage.
I am a Codeigniter fan but those objects are huge and it would be highly unwise to store them. Security is another factor - if you are on a shared server and there is a chance of security credentials being held in the object then storing these may also be unwise.
I do store objects in a database but just make sure Garbage collection is working. If you use a database there is a bug in Ubuntu where the collection doesn't run - in which case you need to force it through ini_set.
I am planning and researching my switch from MySQL to MongoDB right now and I just had an interesting thought... I have a bunch of hierarchical objects that I need to store in the database. My current method is to have a bunch of embedded documents in a collection. They will never need to be searched for. Would it possibly make sense just to serialize the PHP objects, stick them in the DB, and then unserialize them back into PHP objects when I want to use them? The alternative is using Doctrine as my ORM.
My programming intuition tells me that this is bad design and is limiting, but I feel like serializing and unserializing would be very fast and eliminate the need for an ORM.
What's your opinion? Good design or bad design?
In many cases this would be considered bad design, but it could work if all of the following apply:
You don't need to search on them
You can accept (potentially) limited ability to query on them
You don't need relational integrity or other constraints enforced by the RDBMS
You know you'll never need to read them in a different language
You're confident that you'll know how to deserialize, version, and migrate them properly when you update your class definition
You're confident that the PHP serialization format will be stable across releases (or you are willing to write migration code, or it's a short-term project and you don't care)
You're willing to accept a minor performance penalty (SELECT + deserialize() will be slower than just SELECT)
Why use a database if you can't query it ?
It kind of depends entirely on what you intend to do.
If it's always the same object each request deals with or there are no relationships between each request, it might be ok.
But to me there are a lot of downsides:
You might want to do something more advanced to the objects later
Serialized objects are kind of unreliable (not exactly ACID compliant)
There's nothing else that can read a serialized php object, you might want to use something else instead.
Serializing objects is VERY useful when you have to cache things, such as RSS feeds.
I find it good use to serialize it, but I would also make sure that that can never be editing as a string without unserializing it first!
I find myself converting between array and object all the time in PHP application that uses couchDB and Ajax. Of course I am also converting objects to JSON and back (for sometimes couchdb but mostly Ajax), but this is not so much disturbing my workflow.
At the present I have php objects that are returned by the CouchDB modules I use and on the other hand I have the old habbit to return arrays like array("error"=>"not found","data"=>$dataObj) from my functions. This leads to a mixed occurence of real php objects and nested arrays and I cast with (object) or (array) if necessary. The worst thing is that I know more or less by heart what a function returns, but not what type (array or object), so I often run into type errors.
My plan is now to always cast arrays to objects before returning from a function. Of course this implies a lot of refactoring.
Is this the right way to go? What about the conversion overhead? Other ideas or tips?
Edit: Kenaniah's answer suggests I should go the other way, this would mean I'd cast everything to arrays. And for all the Ajax / JSON stuff and also for CouchDB I would use
$myarray = json_decode($json_data,$assoc = true); //EDIT: changed to true, whcih is what I really meant
Even more work to change all the CouchDB and Ajax functions but in the end I have better code.
Generally speaking, you should always use arrays unless there is a good reason to use objects. And the only good reason to use objects over arrays in PHP is if you need some sort of functionality for your data that arrays do not provide (such as private / protected variables, methods, object magic, defined structure, etc). If you're dealing strictly with data, array format is better because you can easily manipulate your data using PHP's vast array of array functions (no pun intended).
UPDATE:
If all you are doing is passing data between two points, arrays are much more suited for that purpose. The only reason (as far as I can tell) that one would ever use an object over an array as a mere container for data is if the receiving side needed a guaranteed format (think interfaces, etc).
From what I can tell, you should be returning arrays from CouchDB to avoid having to convert altogether.
It depends on the paradigm you want to work in. Fundamentally your data is all key-value pairs stored in CouchDB. Maybe it can be easily mapped to objects/entities and you are more comfortable thinking of it in terms of objects that have properties and methods. Or, maybe not and maybe you are more comfortable working with the raw data without the abstraction that classes provide. I think this is the key distinction that should inform your decision.
There is not a lot of overhead involved with objects vs. arrays in PHP. Internally they are treated similarly by the PHP engine. You might want to benchmark it yourself if it's a concern, but I think that you won't find a lot of difference unless you are pushing massive traffic or have a very constrained server. Obviously your web app would be faster if you wrote it in optimized x86 assembler, but you don't do that because you want to be able to enjoy the convenience that a high-level language like PHP provides. So execute the best design now, and optimize later, if it's even necessary.
In my web app, I have some complex objects written with JavaScript (ie nested arrays, objects within objects withing objects, etc) and the nature of my app relies on these. I need to send all the data to PHP so that I can save it to the database. What is an efficient, easy way to send my objects to PHP? I tried JSON, but got strange errors like 'too much recursion', which I'm guessing means that my objects are too complex for it. So is there a good library of script that will do this? Thanks in advance.
EDIT:
So JSON then. I tried updating the JSON library to no avail, and I am now looking for cyclic references.
JSON is the right answer.
I suspect your JSON libraries are either broken or too restrictive. Check the JSON to see if it's well-formed, and if so, find a better library that can cope with your data structure.
Consider also simplifying the data structure. It may be too complex for your own good.
Pretty much any JSON library will have a too much recursion error if your object has circular references. The recursion limit of the javascript implementations I've tried is well in excess of ~100 levels deep, so your object would have to be really complicated.
You'll want to detect and eliminate circular references before trying to serialise your object using any sort of library.
edit: Just tested the firefox 3.5 and it tops out at 3000 levels of recursion.
I agree- JSON is the answer. I think the error you are encountering may be part of the library you are using...
http://markmail.org/message/2d5lvmdeg2qg55qr
Mentions the same error.
I've used many complex JSON objects and never encountered that error - I'd say something else is at play.