Richard
I think your analysis is too simplistic, I have found n tier Object
Relational systems tend to generate a lot of relatively simply queries
and a cache will benefit them a lot (Bruce's scenario), but
if you have structured your application in a more 2 tier
Entity-Relational manner any benefit from caching is offset by the
complexity (and therefore possible data integrity issues) involved.
Like Bruce I am using an OO factory and the benefit of instantiating
objects from APC versus the DB every time is substantial (90%), If PHP
was compiled it would be even greater
Neven
The thing is, you've got an overhead because of all the factories and
objects and the general architecture that makes you take up so much of
the workload within your application - a place which is too far away
from the data to be able to optimise itself effectively.
As a result of this inefficiency, you are using a cache to compensate,
and regaining some of what you have lost. This is great, I'm glad your
application is working faster as a result, but please don't mistake it
for anything other than a band-aid compensating for your architectural
choices.
To be clear, I'm not bagging on this approach, every application
architecture is a litany of compromises between the problem, the
proposed solution, and the capabilities and resources of the
developers and the client, and mine are no exception. The choice to
utilise an ORM with a cache is not flawed, nor is it uncommon or
unreasonable.
However, as professional developers it is not wise to make the mistake
of convincing ourselves that our tradeoffs are optimal. When we do
this, we lose sight of what the ideal is, and find ourselves
habitually implementing band-aids even when there is no longer reason
to do so.
In general, the closer to the data you are when you chose to
manipulate it, the better the performance. For relational databases,
this means the use of stored procedures, views, checks, indexes,
partitions and all the other things that an RDBMS can provide that
lets you manipulate the dataset from a distance. Effective use of
these tools dramatically reduces the number of queries, the number of
connections, and the amount of load placed on the database. This has
grown even more true in the last decade as databases have gained more
powerful operators, such as PostgreSQL window functions.
There are times when a cache is the appropriate tool for the job,
however it is also the first place people turn for a band-aid when
their architecture is compromised and it comes at a cost in terms of
data coherency. This is why I tell people not to cache until they need
to, for fear they will miss a solution that fits better with their
need.
Regards,
Richard.
On 2 February 2010 17:29, Bruce <[email protected]> wrote:
Hi Richard,
We use an OO model with a factory design-pattern. The factory loads
objects from the database only once and then caches them for the
entirety of a particular transaction. Once the transaction is
finished the cache is dropped. We got an 70-90% performance
improvement just using this approach.
Cheers,
Bruce
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
--
NZ PHP Users Group: http://groups.google.com/group/nzphpug
To post, send email to [email protected]
To unsubscribe, send email to
[email protected]
