Tiery Eyed

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 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 • 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 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? 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 |

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 • 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) • 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 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 ☺ 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 • 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 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 __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 The only one that could have used caching was REST-ish |

Performance Tests • Tests included Get entries Post Message Get Subscribers 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.25 0.2 0.15 Java Restish Soap 0.1 XML-RPC 0.05 0 1 14 27 40 53 66 79 92 105 118 131 144 157 170 183 196 209 222 235 248 |

Get Entries (10 request average) 0.16 0.14 0.12 0.1 Java (10 req. avg) Restish (10 req. avg) 0.08 Soap (10 req. avg) XML-RPC (10 req. avg) 0.06 0.04 0.02 0 1 16 31 46 61 76 91 106 121 136 151 166 181 196 211 226 241 |

Post Message 0.14 0.12 0.1 XML-RPC 0.08 Soap REST-ish 0.06 Java 0.04 0.02 0 1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 |

Post Message (10 request average) 0.09 0.08 0.07 0.06 XML-RPC (10 sec. avg.) 0.05 Soap (10 sec. avg.) REST-ish (10 sec. avg.) 0.04 Java (10 sec. avg.) 0.03 0.02 0.01 0 1 7 13 19 25 31 37 43 49 55 61 67 73 79 85 91 97 |

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=quot;tbbServicequot;> <port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;> <soap:address location=quot;http://tbb/soap.phpquot;/> </port> </service> To <service name=quot;tbbServicequot;> <port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;> <soap:address location=quot;http://tbb/soap.php?use_remote=1&debug_port=10137&start_debug=1&a mp;debug_start_session=1&debug_session_id=1201&send_sess_end=1&debu g_host=192.168.175.1&debug_stop=1quot;/> </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=quot;tbbServicequot;> <port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;> <soap:address location=quot;http://tbb/soap.phpquot;/> </port> </service> To <service name=quot;tbbServicequot;> <port name=quot;Soap_BrokerPortquot; binding=quot;typens:Soap_BrokerBindingquot;> <soap:address location=quot;http://tbb/soap.php?no_remote=1&debug_port=10137&start_profile=1&debug_start_session=1& amp;debug_session_id=1201&send_sess_end=1&debug_host=192.168.175.1&profile_stop=1quot;/> </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 kevin@zend.com |

Tiery Eyed

by ZendCon on Sep 27, 2008

Accessibility

Categories

Tags

Upload Details

Usage Rights

Statistics

Tiery Eyed — Presentation Transcript