---
title: WWDC2000 Session 404
framework: wwdc
role: article
path: wwdc/wwdc2000-404
---

# WWDC2000 Session 404

## Transcript

Kind: captions Language: en but we're really happy to have you all here except for those of you standing in the back but the overhaul we thank you very much for being willing to stand out there you know who you are we're having some sessions right now but okay now that you built these really cool apps in five minutes or five man months depending on how you're scheduling things it's time to get them out to your customers which is now easier than ever before in Apple history and we're very excited to have Dirk Johnson to tell you all about it so please give a warm welcome to dirt thanks Eddie just hit it high joins the last session of the day we're all ready for it ready to stretch you know I remember I remember when the moment I realized how awesome web objects was how I was about three or so years ago I was working at Apple in the information department information systems and technology I was actually on the Internet services team and we were at that time putting together what is now called the Apple Store Apple online store and we're investigating different technologies that we could use to sort of get this store together and we visited places like Oracle and Netscape and there were some good sites the technologies they presented some bad size cost we were tied in to their engineers for a long period of time and then this from out of the blue this from the side we merged with next and I went up to my manager and I said you know I think it next they have this technology called what web objects something like that and I think it might be what we need to put this store together so my manager being a wise person he was said well hop in the car drive up to Redwood City introduce yourselves and learn web objects so I said okay so Glenn APIs and myself Glenn being the technical the technical lead of our team and I being a programmer went up to Redwood City we literally just drove up with our Apple badges and walked into the reception area and said well you know we're with Apple here's our badge and now secrete like the same company do you mind if we come in and the receptionist bless her heart said sure come on so she opened the door for us and we walked in and we walked around and said hi to people very friendly and we found a couple cubes where they weren't people and we sat down and we started learning web objects it was awesome coming from a Mac development side and coming to the object-oriented side and just learning about sophisticated and elegant technology was was great so Glenn and I decided rather than biting off the Apple store at once well we'd start with a small project so we decided to implement an e-commerce site within Apple for Apple employees to purchase their system discounts their system yearly system discounts and we call that the quarterly promo or the Q promo and for those of you that have been part of the development cycle you know what that's like late nights stale pizza bad jokes and we eventually got done and so we're sitting there and I remember this moment this and those of you that are developers know this moment you look at yourself you've checked off the last feature squash the last bug and you look at each other and you go yes we're done we're ready now what what do we do how can we use an AIX web server to to serve a web objects application how many instances do we need to run how much RAM do we need are you sure we can connect to that Oracle database we'll handle the load thus was born the idea for actually coming up with a way of learning how to deploy web objects application and so we're here tonight I hope to share some of the things that I've learned in deploying web objects applications and I hope that's somewhat familiar to you as well so again my name is Dirk Johnson I'm a now a trainer at Apple what I like to do is first of all go over sort of an overview of the deployment architecture and we're going to detail about some things like configuring and monitoring your website obviously an important part of deployment will mention some troubleshooting skills and techniques because there's no website with it's share of problems and then in the end just sort of bring the ideas together I'd like to go over an example the deployment the nature of deployment is such that some of the subject matter that I'll be going with are a little bit disparate so hopefully I won't lose you hopefully I'll have some good transitions and there's a lot of detail and information in this so I think it will be useful so a very basic deployment architecture would be something like this hopefully it's somewhat familiar when we talk about a web objects deployment architecture sometimes we refer to it as being a three-tier architecture the first tier being the presentation layer made up of the browser and the HTTP server something that's going to be serving your content to your users the second tier is our application layer of course this is where the developers spend most of their time this is your custom logic and of course the third tier being your database layer providing the dynamic content to your site so it's just to consider when you're coming up with your deployment architecture first what operating system we're going are you going to use with web objects we support of course Mac OS 10 server and D for Windows 2000 Solaris and hp-ux and of course with our new announcement Mac OS 10 and Linux with web objects 5 for Java so lots of choices as far as hardware not you know what operating system you're going to use how are you going to set up your hardware processor speed is important especially if you're if you're going to have a lot of traffic on your site processor count for multiprocessor systems the amount of RAM your disk subsystem and redundancy redundant power supplies for example important things to check off your list to make sure you've considered your environments your network speed your network security network security is pretty obvious making sure that people can't get in through the network but sometimes we forget physical security I recall hearing within the last year or so a company was really good and making sure people couldn't hack into their database to get the credit cards so someone decided to go around walk in the door and pick up the physical box and walk out with it so it's important to not let that happen and we we learned that as well at Apple though that didn't happen to us temperature control and even moisture control is important and of course UPS for when the power goes out and make sure and test the batteries under that condition so they last long enough for you that we didn't do that deployment licenses so there's three deployment licenses all the way from work group the desktop the high-end and they each have various capabilities is this right no you're right it's not it's different how is it difference $6.99 $6.99 you get the whole ball of wax the whole eye and deployment pennies on the dollar multi processor multiple instant no volume limit and if you order within the next thirty minutes we'll throw in a pair of Ginsu knives all right we've got that driven home $6.99 have you seen our website this morning it's got $6.99 right on there all right so review the deployment architecture let's talk about the communication that takes place between the application layer and the database layer we do this through something called a database adapter so depending on what platform you've chosen there is a limitation on what databases we connect to so again for example OS 10 has Oracle Solaris as well all the way down the column you can see oracle sybase Informix ODBC but the high point is again web objects v for java so you can see across all platforms well we're supported so it's again an awesome thing so you want to consider your database adapter so now let's talk about the interaction between your presentation layer in your application layer we use something called the web objects adapter well web objects adapter works with the HTTP server with web objects we supply three specific api adapters or or HTTP adapters apache and Safie or whi which is netscape i zappy which is Microsoft and then of course we support the CGI interface with web servers let's talk about that a little bit more first of all the advantage of the CGI adapter is that it works everywhere there's absolutely no place you really can't use it with a web server as a matter of fact we did with the quarterly promo deploy with an AIX web server we recompile the CGI adapter and it worked the disadvantage with it is that it is slower than it's what we call the API adapter just slower than the API adapters because every request forces it to spawn a new process so that's going to be slow it has overhead additionally it's not allowed to use the load balancing algorithms that we have built into the adapt to the API adapters so contrarily the API adapters then do have load balancing which is great for performance the API adapters also operate within the same process as the HTTP server so you've got less overhead there and again we have Netscape Microsoft and Apache support and of course the C source code is supplied for all adapters so you're able to modify their behavior or recompile them for different platforms for the aggressive so let's talk a little bit more about this interaction the adapter with our web objects applications the browser represents of course our user in a request coming in I didn't put the HTTP server there please just assume the request goes to the HTTP server and then gets handed off to the adapter so our user submits a request the adapter looks at the URL that's submitted with the request and as it looks at the URL it looks at what the application name is and what instance of that application that needs to receive that request now the adapter holds configuration information including what instances are running and what hosts they're running on so the adapter is an cross reference that URL with its configuration information and then it will identify the instance and for the request on to that instance so that's sort of a summary of the way that request works with the adapter now what I like to focus on with this slide is really that configuration information because that's really the entryway into your application architecture there so this configuration information first of all the configuration information that the adapter holds is for three separate sets of information first its own configuration information for example what load balancing mechanism is you want it to use second has a list of all available applications and they're in the configuration at the application level and then thirdly you have the application instances and what hosts they're running on and for example their configuration information like port number and instance number the format of all this information is XML but it does still support the old format for those who are used to the pre web objects-- 4-5 format the P list and this configuration information that the a the web web objects adapter has is obtained usually via a URL and you configure that information in the web server configuration file so it's in the web service configuration file that you configure your web objects adapter so let's talk a little bit more about this URL that I referred to that the adapter uses to gather its configuration information first of all there are three ways or mechanisms that your adapter can actually get at configuration information first of all the first mechanism is the typical flat file the first URL that you see there is an example of referencing a local flat file and the second is having a web server deon serving up the configuration information so that's a remote flat file that's pretty straightforward the second way is you can provide an actual hosts list for the adapter it will actually contact these hosts for configuration information there's something I need to introduce here and that's a process that we called low task D this is new with web objects 4 5 it is a process that runs on every one of your application hosts and one of its roles is to supply configuration information for the adapter that is relevant for that particular host that it resides on so in this case we have a host list referencing to hosts Helen and Telesto and Helen and the low testy process is listening on port 1085 so what this means is that the web objects adapter is going to go and connect to Helen on port 1085 which will be the low caste process and that will test the process will return its XML information its configuration information for that box in this case the adapter will combine the configuration information from two protests key processes the third mechanism is multicast and we'll get into that in a minute I want to deal with that in more detail now this configuration information that the adapter caches can become stale so by default the adapter refreshes that configuration information every 10 seconds let's talk a little bit more about this low caste process of probably spread your curiosity then as I mentioned it runs on every web objects application server it's very important it started and restarted for robustness by a demon called low service that's on every platform and it supplies the adapter one of its roles is to supply the adapter again with this configuration data again on port 1085 is where it by default listens and communicates that information now it's real primary role not only is to help the adapter and get its configuration information but it's also its primary role is to monitor cycle and restart your configured instances for those that are familiar with web objects previous two four five this was really the role of monitor in the monitor proxy monitor was responsible for actually configuring the instances and making sure that they stayed up if they went down this role has now been moved over to the low testy process and again the low testy process is local to that particular host monitors still exist but it's merely just an interface to low caste an interesting note about the wou caste processes even though let's say that you have your wou testing process you've got any configured various apps to run and communicate with foe testy testy can still serve instances of your application that you have not configured with monitor when your applications start up they send what's call the life beats to monitor to register with low testy I'm sorry sends a live b2o testy to register with it so that what st can also service those instances that say you start manually from the command line so it's not necessary to configure it with monitor in order to for well test you to service your instances let's make that a little clearer here here we have two hosts Europa and Callisto pay attention to those names those hosts application hosts are running will task be again on port 1085 you have your web objects adapter sitting there you start up let's say four instances two on each they send their life beat to low teske letting low test you know hey I'm ready to go in your web server configuration file you've configured your web objects adapter with a host list where it will look for its configuration information in this case you're open Callisto again and it will then communicate at every ten seconds with low-caste import 1085 and build its configuration information okay so now let's talk about this multi casting it's similar to the hosts list but a little more flexible as a matter of fact let's talk about the flexibility first of this host list what's the advantage of the host list let's say over the flat file well the flat file doesn't incur the traffic on the on the network the traffic slight really anyway the advantage to the host list is let's say that you want to increase the performance of your website let's say it's getting bogged down a bit and your honor and you want to add another instance let's say to Europa and Callisto another instance of your application but when those instances start up the register with low task D via the live feed and guess what web objects adapter will refresh its information every ten seconds on the next refresh the row testy process will alert the adapter to the other processes that you've started so without you having to do anything with the web objects adapter you've actually scaled your site's seamlessly so that's one of the advantage of the host list now let's talk about multi casting so multi casting is actually a network protocol it uses an IP address from the administrative leaf scope domain web objects has used this particular IP address that you see up here - 39 128 14 - no need to memorize it it's written down I can't memorize those um administrative leave scope domain what does that mean it's an IP in the range of IPs that are for internal use to a private network and again it broadcasts on port 1085 when the load testing processes start up they register to receive a multicast on that particular port at that particular IP by default a multicast is limited to the particular subnet on which it is on which it resides on which it is broadcast but if you configure your router to pass on multicast packets you can actually use this multicast or each other subnet so it's an important point so vote SB I'm sorry so the adapter then if it's set up to use the multicast well then broadcast this multicast out on the network and all load test is because they register to listen for this multicast will then register themselves with your web objects adapter what this allows you to the adapter to do is build a dynamic host list now this broadcast this multicast is sent out by the web object adapter every 100 seconds so it rebuilds that dynamic host list every 100 seconds so the advantage of that is is in the previous example our host list if we added a new instance it was automatically detected by the adapter however what if we add a new host okay the adapter is not going to know about the new host because we already have a static host list so the advantage of the multicast then allows us to add an entirely new box to our application layer and the adapter will automatically see that within a hundred seconds or less all right so they'll get a little graphical representation of this again we'll use your open callisto our caste processes and in the web server configuration file we've configured our web objects adapter to use the multicast way of configuring it of getting its configuration information start our instances they register with what test eve with life beat we send out the multicast and dynamically build our hosts list and then based on that host list every 10 seconds will query the hosts on that host list for the configuration information alright so let's see sort of review we know what our deployment architecture is or three layers presentation application database we talked about the database adapter and the web objects adapter well let's say that you get your site set up and you go to hit your website for the first time you're configured let's say your adapter to use the multicast that instance is running and you go to hit your website and things just don't work let's say that the application isn't found what kind of troubleshooting can you do well there's a couple things we can do first of all we can actually query the web objects adapter to see what configuration information it has and it'll present it to us in a very readable fashion right in our web browser so here you can see our HTTP server is called over on the path to the web objects adapter cgi-bin slash web objects we're actually sending the X Y Z Z Y command to the adapter how many of your adventure fans anybody recognize that X Y Z Z Y alright good for you guys sort of dates some of the web objects programmers doesn't it all right so you can query it and it'll return detailed configuration information and of course this can be password protected your web servers public you wouldn't want people sort of seeing what your configuration setup is so we make sure and password protect that secondarily you can also turn on adapter logging if you want to see the logging this was this was there and in pre web objects for five simply create a file named log web objects in the temp directory restart your adapter your HTTP server and then your adapter will start with logging out to a web objects log file in the same directory make sure and turn that off when you're in deployment forgot to do that for cue promo learn the hard way on that I'm so glad I didn't start with the story all right you can drastically reduce your performance all right so let's talk about this monitor let's sort of complete the picture we know what what caste does it's really the workhorse now as far as keeping your side up communicating with your web objects adapter let's talk about monitor well it's a web objects application it always has been again it's the interface to a testy monitor will allow you to manage the same instance of monitor will allow you to manage multiple hosts which means you don't need a version of monitor running on every host you can manage your whole website and it also allows you this is where you will configure your web objects adapter and tell it what for example again what type of load balancing to use and this is also password protected all right so I'd like to introduce Melissa Turner which is a web objects engineer and the web objects team we'd like to demo monitor for you and show the interaction again between the adapter audacity and monitor am i yes I'm connected that was kind of important so basically Dirk has talked about all the various components and I'm sort of going to show you how they can be used in a deployment situation what I have running right here now is an instance of the monitor application it's actually running on a box that we have hiding behind stage and what I'm going to do is well add a host I've timed out how many of you have seen that before how many of you saw Steve demo at Macworld where you saw that a whole bunch so I've added the host that as you can see the solaris box running backstage we thought we'd show you that yes laris actually works because we know that a lot of people actually deploy on Solaris what I'm going to do now is add an application and we're going to hope I don't have typos in it this is basically the defaults that will be used whenever you create a new instance in this application we have a path wizards that you can on the host that you want to create the application on navigate down through the directory structure to actually find that application it saves you having to memorize where things are on various machines [Applause] and this is a difference that some of you will notice between web objects for OU and web objects for five now you have to actually navigate down into the da and select the executable instead of simply selecting the dot Walla one of the advantages to that is that you can actually set up a script and navigate down to an executable script that can set up an environment and then launch your application you like us you really like us okay so I set up my defaults for the incidents so I'm going to go off and add an instance leap I knew I forgot something and at this point I want to show you we talked about X Y Z Z Y I want to show you what the adapter sees this is the X Y Z Z Y command that you can use to get configure it to sort of view the configuration information at the adapter and if i refresh it you'll see that right now the only thing the adapter knows about is the instance of monitor that's running backstage but if I go over here and start the application give it a few seconds to register with low-caste you'll see that the application is running and when I go back to X Y Z Z Y and refresh there's my application and just to prove that it actually is a real application you'll notice that I am going act I'm actually going through the web server I'm not just hitting it through Direct Connect the thing can be a yes I'm an engineer oh they're for demos must confuse me look correct voila we have our application you'll notice that we're serving QuickTime it's one of the examples that's included with all of these various web object stuff it's just a little Store application that lets you go buy things my bottom a lot of PowerBook and okay so you've got your application up it's being served and suddenly people are you know they've heard about your site they think it's wonderful they want to come visit it and you decide that you really need to add another instance or several more instances of your application so you can dynamically just add another host add another instance well eg and for some reason it's not wanting to start oh if it did want to start what I'd show you is that well I'd go back over to X Y Z Z Y on the adapter and it would run but for some reason it's not going to so try one more time try one more time the demo gods have spoken and well because of that you won't be able to see the new app coming up and I have no idea what happens but we do this so that other people have problems feel okay about their demos too okay and that's all I really had to show great Thank You Melissa excellent all right so we talked about your deployment architecture whoa testing the adapters let's see what else can we talk about you know how to manage your site start new instances we can schedule downtime and uptime between your instances with monitor and low-caste something else I'd like to jump to now sort of do a shift is let's focus on the application itself your application as you're going through the development cycle it's probably going to behave a little differently than you want it to during the deployment cycle for example well here let me get here first all right there's this notion of public and private resources so while you're going through the development cycle you're really usually launching on the same system you're developing on and all your resources are sort of mingled together well when you go and deploy you've got this HTTP server that needs to be seen by everybody on the Internet and I'll say on a static site your pages your HTML pages reside on your HTTP server because they're publicly accessible to the people need to get to it your images are on your HTTP server your sounds etc anything you might have well your application because you have this dynamic application there's some resources there that we don't want to be accessible to the public for example your executable you don't want someone taking that how about your components or your pages their definitions how about the model file Mike showed you that the model file contains your database information including name and password so you definitely don't want that going out and sitting on your HTTP server so again there's this notion of public resources and private resources and you want to keep those separate with the web objects application when you get ready for deployment we do something that we term a split install so you want to make sure and do that as a matter of course when we did the the cue promo it was my habit to just compile the application copy the whole dot wallet folder the folder with everything in it and just copy it over to the document root of the HTTP servers so my images and stuff would get there well they got there but what everything else so that was a bad practice that I had to get curbed quite severely so you want to make sure and do that split install and keep those resources separate yes back up we have roses on we if you're this is sort of in the notion of troubleshooting if for some reason you you know if you do your install you have your app running you're trying to hit it through the adapter and your images aren't loading probably means that you've forgotten to copy your public resources over to your web server we got actually caught by that yesterday when we were trying to get our demo set up our QuickTime files weren't coming over and that's a really good place to look if you're trying to you know troubleshoot problems schools are showing a matter how often you do it you always make mistakes thanks Melissa all right so application configuration so the behavior of your application during development should not necessarily be the same in production for example when you launch an application in your development environment it usually tries to open up the browser automatically for you well you wouldn't want that behavior and deployment for example so we provided away with web objects about three different ways of configuring the behavior of your application so the first is the defaults database the defaults database is installed when you install web objects it's a database that allows you to store values for command line arguments on an application by application basis so when you launch say the monitor or you launch your virtual store light application it will look in this defaults database under its own name pull out the command line arguments that you have set and add them to the launching of the application there's also an area in the default database called NS global domain which allows you to have settings across multiple applications so any settings in the NS global domain will be applied to any application launching on that particular application host secondarily the actual command-line arguments you can go ahead and launch your application with certain command-line arguments these command-line arguments will override any settings that are duplicated in the defaults database so that's the advantage of using the command-line argument right on the command line is that you can override any settings that you have sitting in your defaults database and finally is the programmer you have ultimate power if you want to hard-code something and make sure that it absolutely we behaves a certain way you don't want anybody anybody changing the behavior you can of course set it in code which would have been override anything that's presented on the command line or in the default database very important for deployment all right so now let's talk about bottlenecks you've gotten your application together you've got it ready for deployments and let's say that actually you put it in what I would call a staging area you have your development area your staging out area which is as identical as possible to your deployment area and you want to do some stress testing on your application and you start running through your application and trying to simulate that load that you anticipate for deployment and you find that it's not performing the way that you need it to these are what we call bottlenecks bottleneck stick performance and these are the very various areas that you would want to investigate where that performance bottleneck might be so first is the application of course in your code maybe your subroutine that gets called with every request response is not performing well and you need to optimize that how about database queries going to the database aren't optimized well especially if you haven't done table indexing or things like that how about your CPU let's say that the traffic that you put on a single host is it's way too much for that processor you need to add a second processor offload it to a second box how about virtual memory or RAM when you launch your application it's going to try and load itself into Ram as you fetch objects from the database it's going to try and keep that in RAM well if you don't have enough of it it's going to start swapping to the database using virtual memory and that's swapping severely degrade your performance so you don't want that to happen how about the performance of the network your applications running fine your database is fine but the communication between the two is severely strained so you need to increase your network bandwidth so these are areas that you want to focus on and looking for the problems the application in the database will be bottlenecks will be talked to in great detail and the optimizing your application session session for 10 so that's Thursday I think so you want to look at that the other three areas I'll address brief and really the hard part about look at this situation this performance problem isn't actually identifying with confidence where the problem is the solution is usually more intuitive so I'd like to just talk about a few utilities that you could use to address these separate bottlenecks so on the UNIX platform Solaris Mac OS 10 Linux for example for looking at your CPU and how its performing using PS are tough like top especially because it's a dynamic update you can actually have the column sorting so you can see what your what percentage of the processor you're using at any one point in time uptime tells you and in three separate numbers how what percentage what the ratio of the processes that your processor is using over five ten and fifteen seconds that's also very useful to get just a quick snapshot of how your processors doing how about monitoring your vm usage you're swapping it goes on well--there's vmstat a vm underscores that depending on what UNIX platform you're on to help look in great detail how the paging is doing and where the where the large amounts of paging is going on you can also use again PS and top because it also tells you how much real RAM and have a virtual memory you're utilizing for a particular process your network packet sniffers there's a lot of them out there Solaris comes with I think it's called snoop Mac OS 10 server comes with TCP dump packet sniffers are very useful looking at the packets going across your network measuring how large they are and looking at the bandwidth that your network has to see if you can either eliminate the traffic on your network or increase the bandwidth of your network there's also net step on NT in Windows 2000 they have more GUI oriented tools which are very good task manager and performance monitor to look at both your CPU and your RAM usage the network on network monitor comes with NP server it's a very useful tool and they have some great filters that help you sniff the lines and and isolate different types of packets and different destination packets so it's very useful all right so we've talked about a lot of things sort of been over the map here and there what I'd like to do is sort of try to bring everything we talked about together in a scenario I'll sort of talk through how I might consider a sample deployment and what what the thought process is that I might go through so here's my set up start with I have a few customers my sights is deployed but maybe it's not very popular at the moment so that's what the red circles are the my browsers to my site here I have an HTTP server called Oberon and of course it's utilizing the API adapter for performance and efficiency I have one host called Europa running two instances of my applications now no matter what no matter even if one instance could really handle the traffic that I anticipate on my website I still want to run two instances for purposes of redundancy if I'm running one instance and it goes down my site goes down if I'm running to my site may slow down but it doesn't go down if one goes down so that's that's why I would have at least two on my site and then of course full boast is my database you always have in that database all right so let's say then well I'm very concerned about my users being able to access directly Europa or access directly my database you notice there was nothing there previously probably did a little too soon whoops you don't want to hit that button okay so I'm a bit concerned about the access that my users have directly to Europa actually they could even talk to low-caste directly couldn't they in this case and get the XML configuration information so that's not a good thing so what I might want to do is put a firewall between my users and my actual deployment architecture here my deployment site now with my firewall I would only want to allow in connections to Oberon on port 80 port 80 being the default port for HTTP servers and that way even if the users try to connect to Europa the packets won't go through the firewall so that's a very secure setup so the first thing I would be concerned about is implementing a firewall between your users and your website secure that web now let's say that our site becomes more popular and we get more users well let's say I use an old AIX box on the back of the room and the more users put my HTTP server under load and I'm going to have to add a second HTTP server well the advantage of the web objects architecture the way that it's modularized to these three tiers is that you can scale the tiers individually very flexible so what I'm going to do is I'm going to add a second HTTP server I'm going to call it Oberon - and notice that it's also using the API adapter of course I'm gonna have to rename the first one to Oberon one because well it just sort of syncs up better now wait a minute well there's a problem here the firewall is only allowing packets into Oberon on port 80 I suppose what I could do is change it to allowing packets on over on one and over on to through port 80 but then the user would have to choose which one to hit and then it really wouldn't be scaling my slide very well and a very intuitive fashion for the customer so I'm going to introduce to something called round robin well that was fun let's try that again round robin DNS get it all right round robin DNS and rather round robin DNS server is going to sit there and listen for packets for Oberon on port 80 and then it's going to take care of managing it managing it across your HTTP servers okay great let's see what's next alright we get more servers we're more popular things are going great and now your rope is having a hard time handling the traffic let's say so that means we can scale our applications here and we're going to add kalisto and two more instances of course on callisto for the same reason that I spoke of previously if I was having at least two instances per host but you know I would say something here and that is if you can afford it not only would I have two instances on every host at least I would always have at least two hosts serving in my application layer because just like if an instance goes down my host site doesn't go down with the second instance what if the whole box goes down you always want that redundancy that second server there handling the site even though it's going to be at a slower pace until you can get that second box back up so really if you can afford it I would always have two of those there all right let's see we have redundancy on the HTTP server redundancy on the application tier let's see what else database let's consider the database well if we really want our site to be very robust we're going to need to come up with a solution for if the database goes down what we can do firewall sorry all right actually that's the wrong order let's see if we all right pretend the firewall then come up all right so we have what we want to do is have a second database come in and we'll call it demos in this case so Phobos and Deimos Deimos is going to be a mirror of Phobos every insert update delete that occurs in Phobos is going to occur in Deimos so that they're identical at all times and that way if Phobos goes down you can now write your applications with web objects for five to seamlessly connect to Deimos and continue processing while your suicide mint is page to look into why Phobos went down get Phobos back up get them back and sync and then you're back in business again so it's a very flexible scalable architecture across the three tiers now the firewall that sort of popped up in the middle not every site has it but I like to separate with a firewall my public resources for my private resources again it just makes things extra secure you recall you know we don't want people walking away with our database servers and we don't want people being able to hack into them as well so what I might do is add a second firewall between my excuse me my HTTP servers my application servers and only let packets through to my application servers that way if some way someone's able to tunnel in through port 80 and get access or control of Oberon Oberon cannot connect under any circumstance to Phobos with that firewall there so again an additional barrier all right so that type of setup is generally called a border zone where you separate your public resources from your private resources physically with a firewall of course separating an inch of private network and of course your public access internet or intranet all right so that's a sample deployment that's pretty much it but you know I realize there's still really one question that I have an answer and that is the now what how many instances do I run how do I know how much ram what am i go what should my architecture be I think it's a big question and about a year ago I started asking myself how I could figure it out is there some magic formula that we could come up with that would tell us how many instances to start with and by golly there's absolutely no way to do it but I think that's true I think we came close though let's give it a try it's all theoretical but we created the deployment calculator this is the first public rollout of the deployment calculator we're going to ask Melissa to show it to us all right Melissa and yeah this isn't actually a Mac box where you know proving that we work on all systems actually I'm going to talk a little bit more about troubleshooting stuff as you can when you start an application if you start it from a shell and start it with the commands or the command line parameter whoa debugging enabled it'll print out all kinds of stuff to that shell so if you're trying to debug problems in your application or in your configuration this can be helpful but we've got a deployment calculator and what we're going to try and calculate is how many instances of our application we need running and there's a few this is courtesy of dark and there's a few things we've determined they're kind of sort of they're the status the measurements that are important these are the things that really sort of influence how many how many instances of your application you run things like loop time which is how much times take your application to run through the critical path of the incoming requests max wait time is sort of how long do we want our users to have to wait how long do we think our users will be willing to wait for to receive a page back how many transactions is my site likely to be receiving per day and sort of on the more web object side how long does it take for my sessions to time out how big is my application when it has one session that sort of gone through that what we have deemed the sort of standard path through our site how big is it when ten sessions have gone through how long our users likely to spend on any given page and how many pages are they likely to hit during a visit and now why don't we say that we think it's going to take about a second for our application to run through the critical loop and we think yeah we'll make our users wait for seconds and I don't know half a million transactions a day sounds now reasonable for you know brand-new site doesn't it think positive and we'll set you know 30 minute timeout we think people be around for a while initialized with one session is at 22 megabytes with ten sessions at 30 megabytes and we think people will take about 20 seconds to look at each page to read over the stuff and decide what they want to do from here they'll probably hit that are now 15 pages per visit we scroll down to the bottom hit the calculate button and it says oh there's your result because you probably want six instances running there's more stuff down here this is sort of this is the how many transactions will how many requests will be queued okay in a typical cycle to not exceed the maximum wait time this is you know your transactions per day divided up into well hours minutes seconds your ideal instance count as six as we said this is some round calculations each session is going to take about eighty Meg your application horny corn eight Meg that's a large session you're doing something wrong there you've got your entire database in there now the application itself takes about twenty 1.2 Meg session the average session length looks like it's going to be but little over three hundred seconds you'll deal with you know sessions per hour this is yeah I can I'm just trying to translate it into English a little over without 1300 sessions per hour and you'll have it on average 18 or 819 sessions active at any given time which means you'll have a 778 Meg's worth of application at any given time over in this list we sort of show you what the maximum this configuration can handle is likely to be a maximum number of transactions per day transactions per hour now what maximum session length is and when we calculate these numbers it's done on a bell curve where we ask or it's done by averaging out transactions over a day but we all know that there's likely to the transactions are actually likely to distribute it on a bell curve you know California wakes up and the internet slows down type of thing so what you want to do is you want to make sure that your site these numbers here are over the top of your bell curve so that whatever configuration you've got the maximum number of things you can handle according to this transaction is at least what listed in this last column here memory what about the memory and the memory so that so that's your yellow column is your max transactions and so your memory that's the maximum amount of memory that you'd be using if you had the maximum number of transactions so I would always run enough instances so that my it's called my spike transactions per day are higher than your top the top of your highest bell curve and I would always run my memory so I have enough memory across my whole website and this is all logical and logical distribution so that I'm so I would set up with a minimum on this case of 3 gigabytes of RAM on my website with 6 instances as long as my bell curve stay below two million hits per day so what do you think okay why don't you click on the transaction per day hyperlink so there's a glossary of all these terms how I calculated it how we calculated it and it walks you through how to use it and what each of the terms mean I provide the formula at the bottom the source code is there so you can modify your own formula it's all theoretical please use it and give me feedback but we can modify it and it's on your CD in your bag your web objects double CD so it's right there the project and everything so have at it let me know thank you all right thank you Melissa oh let's see well I was exciting public took a really it's been like about a year working on that so again it's in your seat it's in your bag and you can also download it from Enterprise at Apple comm at WWDC mm if you don't get it there all right so roadmap so where do we go from here we've covered a lot of material there's a lot more for deployment web objects optimization Thursday at 9:00 a.m. maximizing performance and also performance metrics I think is very political to deployment because you got to tell where your performance bottlenecks are so you might want to make sure and go there for more information you've seen these URLs before this information before in the previous slides don't forget about the BLF tomorrow night put a contact please send all deployment calculator inform a to vote feedback but there's also in the introduction portion of the deployment calculator there's information where to Ford and feedback on that as well but you can Ford it there and finally QA but wait I get to ask the first question you can put the lights up what was the relationship between all names of the hosts in this presentation Deimos Phobos Kate yes Greek mythology very good I'll accept that but there are moons of the solar system