Re: [fw-general] Zend_Db_Table with multiple databases

[Paul M Jones]

On Sep 16, 2009, at 14:02 , troels knak-nielsen wrote:


Hi.

I'm looking into replacing a legacy system with Zend_Db + subpackages
(Zend_Db_Table and friends), but I'm running into some problems. The
setup we have is a master/slave. For offloading the main server all
read queries are channelled to the slave, while all write queries are
sent to the main server. The current library supports this by allowing
each method to fetch the appropriate link. From what I can see, there
is no direct support for such a thing in Zend_db_Table, but I can see
a couple of possible flex points in the framework.

Before I start off a tangent myself, I was wondering if anybody else
have tried something like this?


Hi Troels,

You may find this earlier thread useful:

  http://www.nabble.com/Best-practice-for-Master-Slave-Db-w--ZF--td24179039.html

In particular there is this bit about Solar, which obviously is not  
Zend Framework but may provide useful hints.


  
http://www.nabble.com/Re%3A-Best-practice-for-Master-Slave-Db-w--ZF--p24204672.html




This is as opposed to Solar's MysqlReplicated adapter, the SVN trunk
version of which works automatically.  Yes, it examines the first few
characters of the SQL statement to determine whether it should pick a
master or a slave, which is not exactly a big performance drain.  It
also manages GET-after-POST situations, so that if you insert or
update on one request, the very next request *also* uses the master
(even for reads), to allow time for data propagation to slaves.
Finally, you can switch back and forth between replicated and non-
replicated environments without changing your application code.

See more here:

   http://solarphp.com/blog/read/19-adapter-for-master-slave-my-sql-setups









--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Sorting with Zend Lucene

[Paul M Jones]

On Jul 1, 2009, at 12:26 , Matt Schraeder wrote:

On closer inspection, it seems that foreaching through the hits  
alone is enough to cause a memory usage to climb.


foreach ($hits as $hit) {
 echo $hit->SomeData;
 echo ''.memory_get_usage().'';
 @ob_flush();
 @flush();
}

It looks as if each time through the loop, the previous $hit is  
still in memory.


Perhaps this blog post has relevance:

  http://paul-m-jones.com/?p=262

Excerpt:

If you have two objects in circular reference, such as in a parent- 
child relationship, calling unset() on the parent object will not  
free the memory used for the parent reference in the child object.  
(Nor will the memory be freed when the parent object is garbage- 
collected.)



--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Best practice for Master/Slave Db w/ ZF?

[Paul M Jones]

On Jun 24, 2009, at 02:49 , keith Pope wrote:


2009/6/24 wadearnold :


I'm looking for a sanity check for my ZF connection to a mysql  
master/slave
architecture. My Db configuration is MySQL Master and three slaves.  
The
three slaves are behind a load balancer with linux hearbeat so to  
php the

slaves are a single connection. To date I have been using two Zend_Db
connections and then remembering in my code were to read and write:

// using mysqli adapter
$master_db = Zend_Db::factory(...);
$slave_db = Zend_Db::factory(...);

$master_db->insert(...);
$master_db->beginTransaction();
$master_db->update(...);

$slave_db->fetchAll(...)
$slave_db->select(...)


I have seen other frameworks abstract the first part of the sql  
statement
and find the proper db pool. I am not sure if this is worthwhile  
and seems
like a lot of work for PHP. There is not an equivalent in the Zend  
Framework

correct?
http://solarphp.com/class/Solar_Sql_Adapter_MysqlReplicated

I am starting a large application and don't want to come begging  
back to the
list when it does not work. Does my implementation seem sufficient?  
Links to

best practices would be great!


I would suggest doctrine, its far more mature than Zend_Db and has
support for what you are looking for


[FULL DISCLOSURE: I am the lead developer and architect of Solar, and  
was the initial developer of Zend_Db and Zend_Db_Table way back at the  
beginning.]


Per this Doctrine page ...

  
http://www.doctrine-project.org/documentation/cookbook/1_1/en/master-and-slave-connections

... it looks like there is no functional difference from the Zend_Db  
approach outlined above.  That is, you should create multiple  
connections, and pick manually which one you want to use.  The  
Doctrine example instructs you to do that in extended classes, which I  
guess Zend_Db is also capable of.




This is as opposed to Solar's MysqlReplicated adapter, the SVN trunk  
version of which works automatically.  Yes, it examines the first few  
characters of the SQL statement to determine whether it should pick a  
master or a slave, which is not exactly a big performance drain.  It  
also manages GET-after-POST situations, so that if you insert or  
update on one request, the very next request *also* uses the master  
(even for reads), to allow time for data propagation to slaves.   
Finally, you can switch back and forth between replicated and non- 
replicated environments without changing your application code.


See more here:

  http://solarphp.com/blog/read/19-adapter-for-master-slave-my-sql-setups




plus doctrine 2.0 (not released yet though) should have good support  
for domain modeling...


Ah, the joys of unreleased software; it will do everything, just not  
yet.  ;-)




--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] disable magic_quotes_gpc

[Paul M Jones]

On Jun 17, 2009, at 16:14 , MarkDNA wrote:


Mantasgl wrote:


Hi,

I found that in my hosting company magic_quotes_gpc is on by default.

I can't turn them off in my .htaccess file, I get internal sever  
error. I

used both:
php_flag magic_quotes_gpc Off
php_value magic_quotes_gpc Off

I solved this problem by adding this code in my bootstrap:
if (get_magic_quotes_gpc())
{
function stripMagicQuotes(&$value)
{
$value = (is_array($value))
   ? array_map('stripMagicQuotes', $value)
   : stripslashes($value);
return $value;
}
stripMagicQuotes($_GET);
stripMagicQuotes($_POST);
stripMagicQuotes($_COOKIE);
}

Is this a good tecnique? Maybe there is other solutions?



That's pretty much what the php manual has for the situation. A note  
- your

stripMagicQuotes() returns a value, so you need: $_GET =
stripMagicQuotes($_GET); and so on.



A similar plan is outlined here:

  http://talks.php.net/show/php-best-practices/26

To wit:

if (get_magic_quotes_gpc()) {
$in = array(&$_GET, &$_POST, &$_COOKIE);
while (list($k,$v) = each($in)) {
foreach ($v as $key => $val) {
if (!is_array($val)) {
$in[$k][$key] = stripslashes($val);
continue;
}
$in[] =& $in[$k][$key];
}
}
unset($in);
}

Solar does this automatically in its Solar_Request::reset() method;  
you can see actual usage there if you want other security/convenience  
hints:


  <http://svn.solarphp.com/core/trunk/Solar/Request.php>

Hope this helps.


--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Is Cal Evan's Globals.php a recommended approach

[Paul M Jones]

On Jan 13, 2009, at 10:55 , Ralph Schindler wrote:


First, the __construct($options = array()) {} convention for the most
forward facing component API constructor adds a level of consistency  
that
makes each and every component look and feel similar in style.  This  
would

makes it easy to move from component to component and have a good
understanding of what is expected.

...
I believe this convention is very much used in Solar and its  
becoming more

popular in ZF as we see more components hit the library.


Correct.  In Solar, it is used always and only; that is, every  
constructor for every class is identical:


public function __construct($config = null) { ... }

It helps to standardize configuration of instances and aids greatly in  
Dependency Injection and Service Location.  I call this a "universal  
constructor."  I don't know if this pattern has been cataloged anywhere.


You can read a bit more about it on these pages:

- <http://paul-m-jones.com/?p=197> (old but mostly valid)

- <http://solarphp.org/manual:project_standards:constructor_parameters>


--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] ZF Best Practices for someone who has been using Cake

[Paul M Jones]

On Nov 6, 2008, at 08:37 , Matthew Weier O'Phinney wrote:


-- Steve Klabnik <[EMAIL PROTECTED]> wrote
(on Thursday, 06 November 2008, 09:23 AM -0500):
On Wed, Nov 5, 2008 at 6:23 PM, Matthew Weier O'Phinney <[EMAIL PROTECTED] 
>

wrote:

   There's not. I'm not entirely sure why Zend_Db_Table does not  
implement
   this, though my understanding is that there are some sound  
architectural
   reasons not to do so. I've often created such a method myself,  
though,




   Again, there's not, and again, uncertain as to why. I've often
   implemented such functionality for my own models, however.


I'm pretty sure that Cake tries to emulate the ActiveRecord pattern,
and Zend does not. I did a quick search, and it seems like some
ActiveRecord-ish stuff was proposed for Zend back in 2006, but never
took any ground?


Yes. The reason was that PHP currently does not support a pure
ActiveRecord implementation due to lack of late static binding (LSB --
which will be available in PHP 5.3.0).


"Pure" is in the eye of the beholder.  ;-)

The Rails Active Record implementation uses static finder methods, and  
Cake tries to emulate that using instance methods.  Fowler [1] notes  
that static finder methods "typical", but he goes on to say:


"However, there's no reason that you can't separate out
 the find methods into a separate class, as I discussed
 with Row Data Gateway (152), and that is better for
 testing."

So it seems perfectly acceptable, from an implementation and "purity"  
point of view, to have a Table Data Gateway (the finder) return Active  
Records.


Regardless of the *name* of the row class, if it can contain business  
logic that operates on the row, it can fairly be called an active  
record implementation.


(FYI, Solar <http://solarphp.com> works in a similar manner, with a  
table/model class to represent the table, and a record class to  
represent the resulting record (and its related records, if any).  I  
might argue that the Solar implementation is more sophisticated, but  
I've self-promoted enough at this point.  ;-)



[1] Fowler, Martin.  "Patterns of Enterprise Application Development."  
Page 161.




--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Framework speed shotout -- question

[Paul M Jones]

On Nov 2, 2008, at 18:06 , Matthew Weier O'Phinney wrote:


This is true also on Linux desktops. As I've been benchmarking and
profiling ZF for the 1.7.0 release, I've occasionally run benchmarks  
on

my own machine (which runs Ubuntu). Interestingly, I often get very
different results than when I run on a machine setup specifically as a
production environment for benchmarking. Whenever I have doubts, I try
on the production-tuned environment for a sanity check.


Would you care to share the various settings and tunings so the rest  
of us can attempt to repeat your experiences?  :-)




--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Zend_Markup is ready for review

[Paul M Jones]

On Oct 25, 2008, at 08:46 , Pieter Kokx wrote:


Hi,

I'm happy to tell you that Zend_Markup ready for review. I'd  
appreciate all your feedback.


Proposal URL:
http://framework.zend.com/wiki/x/3KQ


Here are some references to other projects that do something similar  
(i.e., use pluggable rulesets to convert wiki-like markup to HTML or  
other formats):


Text_Wiki
: <http://pear.php.net/package/Text_Wiki>

Solar_Markdown
: <http://solarphp.com/package/Solar_Markdown>





--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] Framework speed shotout -- question

[Paul M Jones]

Hi all,

No mention of benchmarking is complete without me hawking my own  
research.  ;-)


The latest report is here:

  http://paul-m-jones.com/?p=315

Attentive readers will note that I take great care to compare each of  
the framework systems on a level playing field.  For example, database  
access is turned off (for those systems that try to connect  
automatically) and config caching turned on (for those systems that  
use non-PHP config files).  The full methodology is outlined in an  
earlier report here:


  http://paul-m-jones.com/blog/?p=236

The entire benchmarking suite and setup instructions are publicly  
available, unlike any other benchmarking report I know of:


  http://code.google.com/p/web-framework-benchmarks/

This means you can run it yourself and critique it with complete  
access to how it works.


The Yii benchmarks lack rigor and, I think, are not worth consideration.



--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] FYI: new php framework benchmarks

[Paul M Jones]

On Sep 2, 2008, at 11:55 , Matthew Weier O'Phinney wrote:


-- Michał Minicki <[EMAIL PROTECTED]> wrote
(on Tuesday, 02 September 2008, 06:30 PM +0200):

Paul M Jones wrote:
Anyway, this only shows that some frameworks are better optimized  
to

display "hello world" than others.

This is **not** correct. Every line of application code added to the
dispatch cycle will only reduce performance, so when you are
attempting to improve the speed of your application, these results
show exactly how much room for improvement you have.


Let me just make everything clear. What Paul is getting at is that  
you
can't get any better response times than the hello world  
application. If

you're hitting those numbers you just can't go any faster. There is
nothing more you can do about it but to customize the framework code.


Not entirely what he's getting at. What he's saying is that without
caching, this is the baseline. You can definitely add caching to speed
up the processing, and only if you still need additional performance
should you start customizing the framework code.


Matthew, that's pretty close, but not quite the whole thing.

You can cache processing results (either data or views), but if that  
caching happens at the action-method level (which I think is the most- 
likely case), then you are not likely to see any increases past the  
results I've posted.   This is because the dispatch cycle has to pass  
through the bootstrap, front controller, page controller, and action- 
method to begin with; the only part that remains is the action-method  
code and the view rendering.


In my testing, there is no action-method code, and you can't get  
faster than "do nothing" there.  Similarly, the view rendering is only  
to present a static text "hello world" and I don't expect a caching  
system will be able to outperform that.  So the results I show are the  
fastest a dynamic dispatch can occur.


Full-page caching will *definitely* speed things up, but that is only  
because the framework is being sidestepped entirely; the web server is  
sending a static (cached) page from disk at that point.


Hope that helps to illuminate the testing results more clearly.








--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] FYI: new php framework benchmarks

[Paul M Jones]

On Sep 2, 2008, at 11:30 , Michał Minicki wrote:


Paul M Jones wrote:

Anyway, this only shows that some frameworks are better optimized  
to  display "hello world" than others.
This is **not** correct. Every line of application code added to  
the  dispatch cycle will only reduce performance, so when you are   
attempting to improve the speed of your application, these results   
show exactly how much room for improvement you have.


Let me just make everything clear. What Paul is getting at is that  
you can't get any better response times than the hello world  
application. If you're hitting those numbers you just can't go any  
faster. There is nothing more you can do about it but to customize  
the framework code.


That is exactly right, sir, and thank you for helping to clarify.  :-)



--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] FYI: new php framework benchmarks

[Paul M Jones]

On Sep 2, 2008, at 04:27 , Viper X wrote:


Caching metadata gives little performance boost. In my tests (
http://zfsite.andreinikolov.com/2008/08/zend_db_table-time-overhead-about-25-percents/
article is here ) the results showed 9.2 requests per second without
metadata cache and 10.2 requests per second with APC metadata cache,  
so

about 11%


It would make no difference in the published benchmark results;  
database access is turned off, per the outlined methodology.





--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] FYI: new php framework benchmarks

[Paul M Jones]

Hi everyone,

Matthew said:


Also, please remember that these are done without any caching --
opcode or content.


Opcode caching is turned on, per the methodology outlined in the  
earlier reports, which I recommend everyone read:


* <http://paul-m-jones.com/blog/?p=236>
* <http://paul-m-jones.com/blog/?p=238>

(I refer to those reports at the very beginning of the latest article.)

The opcode cache is XCache.  The reason for this is that I originally  
did some comparisons with Lighttpd+FCGI and Apache+mod_php, and APC  
did not play well with FCGI at the time.


Regarding content caching, 2 points:

1. A full-page static cache will give responsiveness equal to the web  
server, so it's not a measure of the framework.  We already know how  
fast the web server responds (2300 req/sec) and it will be identical  
for any framework that can cache a full page.


2. A view cache, in the minimal "hello world" case, is likely to take  
*longer* respond than simply presenting the view as-is.  This is an  
intuitive hypothesis, not a tested assessment; here is my reasoning.   
The view cache isn't activated until after you go through the  
bootstrap, front controller, page controller, and action method; then  
you need to load the cache object, check to see if the cache exists  
and is valid, and then return that.  That's as opposed to an action  
with no logic that goes directly the to view script, which itself is  
static text only.




They are meant as baseline comparisons only -- what is the base  
performance of each given framework.


This is correct.  The tests measure the outside limits of  
responsiveness.



Karol responded:

Anyway, this only shows that some frameworks are better optimized to  
display "hello world" than others.


This is **not** correct. Every line of application code added to the  
dispatch cycle will only reduce performance, so when you are  
attempting to improve the speed of your application, these results  
show exactly how much room for improvement you have.  This is not an  
assessment of "hello world" optimization, it is an assessment of the  
maximum responsiveness of the framework architecture, specifically the  
dynamic dispatch cycle (bootstrap, front controller, page controller,  
action, and view).




There will be plenty of chances to improve ZF performance,
but so far focus seemed to be on adding features.


There is no such thing as a free feature; adding features that impact  
the dispatch cycle will continue to reduce baseline responsiveness.   
This has been the case across all the tested systems, not just ZF.





--

Paul M. Jones
http://paul-m-jones.com/

Re: [fw-general] ZF Coding Standard: Factories - code completion, direct instantiation

[Paul M Jones]

On Oct 3, 2006, at 12:09 AM, Gavin Vess wrote:

In conclusion, no one has yet proposed a solution that fits the  
ideal above.  I've summarized various syntactical ways of working  
with factories in PHP:


http://framework.zend.com/wiki/display/ZFDEV/Factories




Whoever suggested this particular tidbit ...

for ($i = 0; $i < $argsCount; $i++) {
$argsString .= ($comma ? ', ' : '') . "\$args[$i]";
$comma = true;
}

return eval("return new $className($argsString);");

... should feel embarrassed for even daring to suggest it as anything  
other than as something to avoid at all costs.


My brain tried to pull my eyes out of their sockets and up into my  
skull to keep me from having to look at it; it's that bad.





-- pmj

Re: [fw-general] Coding Standards & ZF 0.2

[Paul M Jones]

On Sep 30, 2006, at 11:55 AM, Jeff Moore wrote:

Seriously, the important thing is to have a standard, not so much  
what the standard is.  (Unless it is really bad.)  These standards  
discussions always generate heat and friction and not much light.


I generally like the PEAR standard.  Is there a reason not to use  
it?  Why not start with that and say, we conform to the PEAR  
standard, except for these exceptions, and here are some  
additions.  Or if you just can't bring yourself to link to the PEAR  
standard, at least re-state it and adopt compatibility as a goal.   
There is so little to be gained from creating yet another coding  
standard.


Preach the word, brother.  Jeff and I have blogged on exactly these  
issues in the past ...


* <http://paul-m-jones.com/blog/?p=34>

* <http://www.procata.com/blog/archives/2004/09/24/php-coding- 
standards/>


To sum up, I'll quote Jeff:

Having your code in a "normalized" form frees the mind to consider  
other aspects of the code. Poorly or inconsistently styled code can  
obscure refactorings. With a good coding standard, the benefits  
outweigh having to re-train yourself out of a few habits.


The general thesis is to adopt a previously-existing published  
standard (in this case, PEAR) and adhere to it, noting any deviations  
as exceptions.  See also the Solar coding style guide, which is  
composed only of a link to the PEAR style guide and one exception note.


<http://solarphp.com/index.php/docs/read/Main/StyleGuide>



--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.   <http://solarphp.com>

Savant: The simple, elegant, and powerful solution for
templates in PHP.   <http://phpsavant.com>

Re: [fw-general] Coding Standards & ZF 0.2

[Paul M Jones]

On Sep 29, 2006, at 11:16 AM, Darby Felton wrote:


I believe that it is best practice to have the braces, even when not
technically necessary, for clarity and elimination of a common entry
vector for bugs.


Hear hear.


--

Paul M. Jones  <http://paul-m-jones.com>

Solar: Simple Object Library and Application Repository
for PHP5.   <http://solarphp.com>

Savant: The simple, elegant, and powerful solution for
templates in PHP.   <http://phpsavant.com>