Personal blog of Yzmir Ramirez

Welcome to the new, ZendCon 2009 edition of the ZendCon Sessions! The podcast that rebroadcasts sessions/talks from the last ZendCon PHP Conference. This episode of The ZendCon Sessions was recorded live at ZendCon 2009 in San Jose, CA and features Sam Hennessey giving his talk: “ PHP – Faster And Cheaper. Scale Vertically with IBM i”

In the previous segment of this article, I introduced you to the Zend_Paginator class, which provides a flexible API for paginating any data collection, whether it is expressed as an array or a database result set. However, Zend_Paginator isn’t the only game in town. There are a number of other open-source PHP pagination widgets, which can be used as an alternative to Zend_Paginator.

With all of the good things that frameworks can provide, there’s still some bad that can come with them. In this recent post from Developr.com Jayesh Kitukale mentions a few of these downfalls.

Welcome to the new, ZendCon 2009 edition of the ZendCon Sessions! The podcast that rebroadcasts sessions/talks from the last ZendCon PHP Conference. This episode of The ZendCon Sessions was recorded live at ZendCon 2009 in San Jose, CA and features Ilia Alshanetsky giving his talk: “ PHP 5.3 == Awesome!”

Rich Internet applications built with Adobe Flex and Flash Builder have been steadily gaining a foothold in enterprise development for quite some time. As the platform has grown and evolved, PHP has also made amazing progress toward becoming a mature, powerful object-oriented language with rapid adoption and dozens of frameworks and design pattern implementations. As PHP continues to prosper, developers are able to borrow more and more of the things Java has got right, taking one check after another from the “Java-only” column. One outstanding example of this is object-relational mapping ( ORM ). A few different PHP ORM implementations are available, and all of them have positive attributes. However, after some experimentation, I’ve found that Doctrine is my favorite.

Troubled with a very manual and inefficient process of creating models for many database tables, I looked into a way of making this process more automated and efficient. Zend_CodeGenerator_Php was my answer.

For those of you monitoring the Zend Framework SVN the last few weeks, you
will likely have noticed a huge surge of activity as contributors have
scrambled to complete code in time for the 1.10.0 release. The release is
getting close, and I’m happy to announce an ALPHA release of 1.10.0.

http://framework.zend.com/download/latest

Please note that the alpha is only available on the ZF site, not from
the zend.com CDN.

We’re hiring. We are looking for the following qualifications:

1. Expert knowledge of MySQL. Not just “certified” — years of production experience with it. You need to know server internals, for example. You need to be able to do anything from optimizing difficult queries to moving high-volume services between data centers without interruption.
2. Expert knowledge of InnoDB. You should understand its inner workings well enough to answer questions about its internals from memory, such as “how does the insert buffer work?” or “how does MVCC work on secondary indexes?” You should also know why it has trouble on some workloads and how to solve that.
3. Expert knowledge of Linux systems administration. You need to know how to solve issues with filesystems, hardware, and networking. You need to be able to use tools such as gdb, strace, tcpdump, etc to solve weird problems.
4. Expert with Apache, memcached, and other technologies you’d typically find in a LAMP application. You need to be able to administer and troubleshoot a variety of popular open-source server software.
5. Proficient with Maatkit and MMM.
6. Proven success working in a distributed environment where e-mail, IRC and voice calls are your only interaction with clients, colleagues and managers on a daily basis. You must be a self-starter.

We need all of the above, but if you’re a little weaker in some areas that might be OK. Highly desirable skills include:

1. Non-core MySQL technologies: XtraDB, Xtrabackup, NDB Cluster, third-party storage engines and appliances, etc.
2. Technologies such as LVS, Nginx, Sphinx, and load balancers.
3. Other operating systems such FreeBSD and OpenSolaris.
4. Amazon’s cloud offerings.
5. Programming languages and platforms, especially frameworks such as Ruby On Rails and Django.

If you think you’re a good candidate, please fill out the contact form on our website. Thanks!

Entry posted by Baron Schwartz |
7 comments

Add to: | | | |

Please help us shape the future of Zend Framework!

We need your input to help us better understand the way ZF is used in the
real world, what’s working and what isn’t, and where you would like us to
invest next. With ZF
2.0 work commencing soon – there has never been a better time to
provide your feedback.

When we’re looking at mk-query-digest report we typically look at the Queries causing the most impact (sum of the query execution times) as well as queries having some longest samples. Why are we looking at these ?

Queries with highest Impact are important because looking at these queries and optimizing them typically helps to improve system capacity, which in the end often improves response time of the system for variety of queries. Also queries causing highest impact often correspond to either frequent or slowest transactions in the system which makes these queries important to look at.

Slowest Queries correspond to bad response times. If there is 30 sec query this means somebody had to wait for 30 seconds which is typically not acceptable for interactive queries. It is best to look at 95 percentile “time” rather than slowest time for the queries as there are often exceptionally high time which you can see which are unrelated to query itself – general system overload, row level locks, table locks all could cause query response time to be unreasonable. If Slowest query is not interactive query, for example part of a batch job it is often fine, assuming it is not causing system overload, interactive queries, which have real users waiting for them are often high priority to be optimized. It helps if batch jobs use different MySQL user compared to the web site itself as it makes it easier to remove such queries from analyzes.

What is Important to mention neither of these two query types really guarantees improvement for application performance (and even more so transaction we’re trying to optimize), it typically does so as transactions you’re trying to optimize typically will manifest itself in one of these query sets.

If you are looking for improving response time of particular transaction/user interaction you really have to look at it, rather than aggregating data for the all server – understanding what queries are being ran (together with other interactions – memcache, remote sites etc) is a key to understanding what causes performance issues.

If you have slow queries from interactive application it is true somebody is suffering (though it is unclear how critical this suffering is) – it is however perfectly possible to get bad performance with MySQL responsible for large portion of response time without any slow queries. We’ve seen pages which take 10.000, 20.000 and even more queries to generate. In such cases even with queries taking 1 ms in average you’re looking at 10,20 or more seconds to respond.

Entry posted by peter |
2 comments

Add to: | | | |