Download - Tiery Eyed
Tiery Eyed - Approaches to tiered development in PHPKevin Schroeder
Copyright © 2007, Zend Technologies Inc.
Kevin Schroeder
Could also be called
“Solving simple problems with complex
solutions”
|
Introduction
• About me
� Kevin Schroeder
� Consultant for Zend Technologies
� Have worked with a bunch of languages
� Have worked with a bunch of hardware
|
� Have worked with a bunch of hardware
� Have worked in a bunch of scenarios
Enough about me
… Almost
• From Canada
• Live in Dallas
• Flew in to San Hose, Eh?
|
Introduction
• What is a tiered architecture?
� Has multiple distinct parts, typically
• Presentation
• Business/Application Logic
|
• Business/Application Logic
• Data
� Often used to provide access to a single layer of logic to multiple informational endpoints
Typical Architecture
|
Why would you want to use a tiered architecture?
• Less sharing
� Reduced replication and/or clustering
• Scale vertically for your data, horizontally for your UI
• Sharing increases complexity
• Less likelihood of invalid or out-of-date data
•
|
• Less duplication
� SELECT * FROM users WHERE user_key = 1 is only called in fewer places
� Easier code rollout
• More options for interaction
• Separated developer tasks
Why would you want to use a tiered architecture?
• It forces you to think about the consequences of
your work
� No more hacking together a simple script
� …hopefully
• It forces you to separate presentation and data
|
• It forces you to separate presentation and data
layers
• Migrate your application to PHP slowly
When is a tiered architecture rational?
• When your development team has highly segmented skill sets� Why force good business logic developers write bad HTML
code?
� Why force graphical people to write business logic? Can they?
|
they?
� Separate your development efforts so people can specialize
• When different parts of your application have different scalability needs� Frontend might scale better horizontally
� Backend might scale better vertically
� Why force both to scale the same?
When is a tiered architecture rational (con’t)?
• When you want to expose your business logic to
multiple different presentation layers
• When you have different programming languages
being used in different tiers
� For example, JEE on the back end, PHP on the front
|
� For example, JEE on the back end, PHP on the front
Why are we doing this?
• Is an N-tiered application a better architecture than
a more traditional web-based app?
� Probably not – depends on your needs
• Then why go through this all?
� To give you some ideas as to
|
� To give you some ideas as to
• What to watch out for
• What the tradeoffs are
• What the performance overhead is
Where are we focusing?
|
What will we look at
• 4 different options
� Soap
� XML-RPC
� REST-like
� Integration with Java backends (PHP preso tier)
|
� Integration with Java backends (PHP preso tier)
• Could also use COM
• Could also use Zend Platform 5250 Bridge, if on IBM i
How was testing done?
• Front end is a Zend Framework microblogging
application
� Only 2 classes
• Account
• Message
|
• Backend is an HTTP server, or the Java Bridge in
front of a simple MySQL database
Let’s look at some code!!!
Option 1 – Soap
• Benefits
� Easy object handling
� Most cross-platform compatible out of all the solutions
• Works well in heterogeneous environments
� Provides highly structured data transfer
|
� Provides highly structured data transfer
� The PHP extension is freaking fast for all that it does
• Drawbacks
� Most complex out of all the solutions in terms of setup
Let’s look at the Soap handling code
Option 2 – XML-RPC
• Benefits
� Pretty lightweight in terms of protocol
� Low barrier to entry
• Drawbacks
� Limited vendor support
� … Except Zend Framework ☺
|
� … Except Zend Framework ☺
� Difficult to use with objects/classes
Option 2 – XML-RPC
• Used SimpleXML
• Why did I not use Zend Framework?
� Performance
� Framework’s XML-RPC framework is great for systems that are loosely coupled
� This application was tightly coupled
|
� This application was tightly coupled
• I had control over the front end
• I had control over the backend
• Therefore
• Introspection was overkill
• I could “bend” the standards a little
• Why did I not use PHP XML-RPC extension?
� It’s still considered experimental
Let’s look at some code
Option 3 – REST or REST-like
• Introduction� RESTful web services typically use XML, bound to a particular URL to
retrieve data� This implementation passed serialized objects instead of XML
• We had already looked at an XML-like implementation
• Benefits� Because it can use GET it is possible to use front and backend caching
together
|
together� Can utilize HTTP header codes� Closest to a native PHP RMI� Gives more control to networking options like persistence if you use
pfsockopen()
• Drawbacks� No real standards� Size limitations on size of GET request
Let’s look at some code
Option 4 – Java Bridge
• Benefits
� Makes it fairly easy to integrate with 3rd party software that is based on Java
� Robust caching options available
� Easy integration into enterprise environments
|
� Lighter communication than HTTP
Option 4 – Java Bridge
• Drawbacks
� Need to know the ins and outs of more than one language
� Need to buy twice the server to due to memory requirements
� Not a shared-nothing environment… but that’s another story
• Things I learned
|
• Things I learned
� __magic methods and variable variables are LOVELY when you are using the proxy design pattern
� Java likes to suck up every free resource on your system…
• Like you didn’t know that (Had to double the RAM on the VM)
Performance Tests
• Done using a custom PHP script to set up
repeatable scenarios
• Tests were done connecting to the front end
domain so that data translation time was included
• No caching was used
|
• No caching was used
� The only one that could have used caching was REST-ish
Performance Tests
• Tests included
� Get entries
� Post Message
� Get Subscribers
� Add Subscriber
|
� Add Subscriber
� Remove Subscriber
• 1000 requests for read operations
• 100 for write operations
� Except for Java. Had difficulty with long-running requests
Get Entries
0.15
0.2
0.25
Java
Restish
|
0
0.05
0.1
1 14 27 40 53 66 79 92 105 118 131 144 157 170 183 196 209 222 235 248
Restish
Soap
XML-RPC
Get Entries (10 request average)
0.1
0.12
0.14
0.16
Java (10 req. avg)
Restish (10 req. avg)
|
0
0.02
0.04
0.06
0.08
1 16 31 46 61 76 91 106 121 136 151 166 181 196 211 226 241
Restish (10 req. avg)
Soap (10 req. avg)
XML-RPC (10 req. avg)
Post Message
0.08
0.1
0.12
0.14
XML-RPC
Soap
|
0
0.02
0.04
0.06
1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96
Soap
REST-ish
Java
Post Message (10 request average)
0.05
0.06
0.07
0.08
0.09
XML-RPC (10 sec. avg.)
Soap (10 sec. avg.)
|
0
0.01
0.02
0.03
0.04
1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97
Soap (10 sec. avg.)
REST-ish (10 sec. avg.)
Java (10 sec. avg.)
Results
• “I thought Java would be slower”
or
“I thought PHP would be faster than Java”
� Java performance was partially due to the architecture of the Zend Platform Java Bridge
|
• It uses a very efficient binary protocol instead of using HTTP as a transport mechanism
� It was also partially because this was not a typically architected Java structure.
• Have you ever run a Java app with only 2 classes?
� It was also partially because Java is faster than most people give it credit for
� Slowness in Java is usually due to architectural decisions
How about debugging?
• Simply add the following query string to the URL that the front end connects to
• For example, looking at the Soap WSDL
<service name="tbbService">
<port name="Soap_BrokerPort" binding="typens:Soap_BrokerBinding">
<soap:address location="http://tbb/soap.php"/>
</port>
</service>
To
|
To<service name="tbbService">
<port name="Soap_BrokerPort" binding="typens:Soap_BrokerBinding">
<soap:address location="http://tbb/soap.php?use_remote=1&debug_port=10137&start_debug=1&debug_start_session=1&debug_session_id=1201&send_sess_end=1&debug_host=192.168.175.1&debug_stop=1"/>
</port>
</service>
• Notice the URL-encoded &
• You can use this string for any of the backend communication methods
… and profiling?
• Simply add the following query string to the URL that the front end connects to
• For example, looking at the Soap WSDL
<service name="tbbService">
<port name="Soap_BrokerPort" binding="typens:Soap_BrokerBinding">
<soap:address location="http://tbb/soap.php"/>
</port>
</service>
To
|
To<service name="tbbService">
<port name="Soap_BrokerPort" binding="typens:Soap_BrokerBinding">
<soap:address
location="http://tbb/soap.php?no_remote=1&debug_port=10137&start_profile=1&debug_start_session=1&debug_session_id=1201&send_sess_end=1&debug_host=192.168.175.1&profile_stop=1"/>
</port>
</service>
Notice the URL-encoded &
You can use this string for any of the backend communication methods
Alternatively…
$sc = new SoapClient('http://tbb/tbb.wsdl');
$sc->__setCookie('use_remote', '1');
$sc->__setCookie('debug_port', '10137');
$sc->__setCookie('start_debug', '1');
$sc->__setCookie('debug_start_session', '1');
|
$sc->__setCookie('debug_session_id', '1201');
$sc->__setCookie('send_sess_end', '1');
$sc->__setCookie('debug_host', '192.168.175.1');
$sc->__setCookie('debug_stop', '1');
Using a tiered architecture for migration
As noted in the (boring :-) ) keynote this morning
� Enterprises are moving from existing environments to PHP
� Why?
• Many applications are more complex than they need to be
• Many applications are simply interfaces to data
|
• Many applications do not really need to be strongly-typed
• PHP flexes to fit the solution. You are not flexing the solution to fit PHP
• Rapid Application Development without losing control (!!)
Questions?
• Do you have any
� Questions?
� Thoughts?
� Experiences?
|
Zend is looking for quality PHP experts in
North America Global Services!!
|