Comments for Alan Seiden's Information Technology

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Aaron Hawley

Aaron Hawley — Thu, 26 Aug 2010 17:01:39 +0000

Yes, usually while building a query you might need to print it and see how it’s coming. I should add, if a query fails to execute, I don’t believe there’s a way to retrieve it from the profiler, so I’ve had to use __toString() in that case as well.

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Alan Seiden

Alan Seiden — Tue, 24 Aug 2010 22:08:16 +0000

@Aaron Hawley
Your comment clarifies the best use of each approach. It seems that:

__toString() is the more flexible option, because it can retrieve SQL for queries that you may or may not have run yet. The __toString() method doesn’t care if you actually run the query.

Zend_Db_Profiler with getQuery(), on the other hand, retrieves SQL for the queries that you actually ran, including any differences created by pagination. It can only be used after the fact, but will be more accurate.

Sound right?

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Aaron Hawley

Aaron Hawley — Tue, 24 Aug 2010 21:45:12 +0000

Sure. Zend_Paginator takes a Zend_Db_Select object and then modifies it (puts FETCH FIRST 20 ROWS ONLY, or LIMIT 20, or whatever your flavor of DBMS requires). These modifications are made to the SQL at the time of sending them to the server. There’s no way to retrieve the query that was *sent* with __toString. Only asking the Profiler will give you the *actual* query used. That’s been my experience, at least.

This *all* assumes you are interested in the row-limited SQL. I know I am!

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Alan Seiden

Alan Seiden — Tue, 24 Aug 2010 21:15:58 +0000

@Aaron Hawley Aaron, thanks for the comment. Could you elaborate?

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Aaron Hawley

Aaron Hawley — Tue, 24 Aug 2010 21:02:14 +0000

Since pagination is used for most all queries these days (thank you Zend_Paginator!) the former has to be used in order to log queries.

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Alan Seiden

Alan Seiden — Tue, 24 Aug 2010 16:02:02 +0000

@Justin Dearing
Justin, yes, there is a database monitor (DBMON): http://www-01.ibm.com/support/docview.wss?uid=nas17b5027600264b165862575fb00710d03

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Patrick Barroca

Patrick Barroca — Tue, 24 Aug 2010 12:15:52 +0000

Well, the magic __toString() is called when you try to echo an object, then your exemple can be even straight :

echo $select;

It is also called when casting :

$sql = (string)$select;

Comment on Two techniques for retrieving SQL from Zend Framework’s database components by Alan Seiden's Information Technology » Two techniques for … | Programming Blog Imagik.org

Mon, 23 Aug 2010 23:21:55 +0000

[...] original post here: Alan Seiden's Information Technology » Two techniques for … No [...]

Comment on Maximize Zend Server PHP performance with Apache compression by Alan Seiden

Alan Seiden — Mon, 23 Aug 2010 22:01:49 +0000

Keith,

Compressed content gets decompressed when it reaches the user’s web browser. The browser controls this process, first sending a “gzip” header that asks the server to use compression, if possible, and then decompressing the content that’s received from the server.

As for your future Citrix environment (where web browsers will run in virtual machines on centralized servers in your data center), the benefits of compression will still be there, but you will probably notice less of an improvement than than if your users connected with browsers outside the network.

With compression, the improvements in speed always depend on these factors:
1. the size and compression ratio of your content (how large the files are to start with and how small they become when compressed)
2. network traffic and speed

Larger files and slower networks (and internet connections) will benefit the most from compression. Smaller files and faster networks reduce the benefits.

Compression/decompression does require CPU on the server and browser, so if the files are small, and served over a fast intranet, the trade-off might not be worth it.

The only way to know for sure is to try with your actual website and network. I hope you’ll give the technique a try and, perhaps, add a comment here to tell us how it went.

Alan

Comment on Maximize Zend Server PHP performance with Apache compression by Keith Livingood

Keith Livingood — Mon, 23 Aug 2010 21:32:59 +0000

Alan,

I have a question concerning your article on Apache compression. In the near future, we are going to a virtual desktop environment/Power 7.1 system i blade and I am wondering if this tip on Apache compression would still be beneficial.

In today’s environment with Apache compression turned on for Zend Server, I understand that a php page would be compressed down and sent over the wire to the user’s desktop. Once it gets to the user’s desktop, does it decompress to present itself?

In a Citrix environment, the creation of the page and the sending of the page would all take place in our data center……could we still gain time if we used the Apache compression? Any help would be appreciated.

Keith