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">


<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">


<soap:address location="http://tbb/soap.php"/>

</port>

</service>

To

|

To<service name="tbbService">


<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!!

|

Contact Me

Kevin Schroeder

[email protected]

|

Technology

Tiery Eyed