But we're really happy to have you all here, except for those of you standing in the back. But those of you sitting down here and those of you in 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 about, now that you've 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 Dirk.

Thanks, Eddie. Appreciate it. So how are you doing? It's the last session of the day. I hope you're all ready for it, ready to stretch. You know, I remember the moment I realized how awesome WebObjects was. It 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 were investigating different technologies that we could use to sort of get this store together. We'd visited places like Oracle and Netscape, and there were some good sides to the technologies they presented, some bad sides, costs.

We were tied into 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 at Next, they have this technology called WebObjects," something like that. And I think it might be what we need to put this store together.

So my manager, being the wise person he was, said, "Well, hop in a car, drive up to Redwood City, introduce yourselves, and learn WebObjects." So I said, "Okay." So Glenn Eppes 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, we're with Apple. Here's our badge.

Now that we're the same company, do you mind if we come in?" and the receptionist, bless her heart, said, "Sure, come on in." 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 of cubes where there weren't people, and we sat down and we started learning WebObjects.

It was awesome, coming from a Mac development side and coming to the object-oriented side and just learning about the sophisticated and elegant technology 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 yearly system discounts.

We called that the quarterly promo or the Q promo. 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. So we're sitting there, and I remember this moment. Those of you that are developers know this moment. You look at yourself, you've checked off the last feature, squashed the last bug, and you look at each other and you go, "Yes!" Done. We're ready.

Now what? What do we do? Can we use an AIX web server to serve a WebObjects 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? Will it handle the load? Thus was born the idea for actually coming up with a way of learning how to deploy a WebObjects application. And so we're here tonight. I hope to share some of the things that I've learned in deploying WebObjects applications. And I hope that's somewhat familiar to you as well.

So again, my name is Dirk Johnson. I'm now a trainer at Apple. What I'd like to do is, first of all, go over sort of an overview of the deployment architecture. Then we'll go into 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 without its share of problems. And then in the end, to sort of bring the ideas together, I'd like to go over an example of 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 WebObjects 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. The third tier is the database layer, providing the dynamic content to your site.

Some issues to consider when you're coming up with your deployment architecture. First, what operating system are you going to use? With WebObjects, we support, of course, Mac OS X Server and T4, Windows 2000, Solaris and HPUX, and of course, with our new announcement, Mac OS X and Linux with WebObjects 5 for Java.

So lots of choices. As far as hardware, I'll let 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 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 environment, 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 at making sure people couldn't hack in to their database and get their 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 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 to desktop to high end, and they each have various capabilities. Is this right? No.

You're right! It's not, it's different. How is it different? $699. $699, you get the whole ball of wax, the whole IAN deployment. Pennies on the dollar! Multi-processor, multiple instance, no volume limit, and if you order within the next 30 minutes, we'll throw in a pair of Ginsu knives! Alright, we've got that driven home. $6.99. Have you seen our website this morning? It's got $6.99 right on there. Alright, so review of 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 X has Oracle, Solaris has, well, all the way down the column you can see Oracle, Sybase, Informix, ODBC. But the high point is again WebObjects 5 for Java. So you can see across all platforms where we're supported. So that'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 and your application layer. We use something called the WebObjects adapter. The WebObjects adapter works with the HTTP server. With WebObjects, we supply three specific API adapters, or HTTP adapters: Apache, NSAPI or WAI, which is Netscape, ISAPI, 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 recompiled the CGI adapter and it worked.

The disadvantage with it is that it is slower than what we call the API adapter. It is 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 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 WebObjects applications. The browser represents, of course, a user and 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. 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. The adapter holds configuration information, including what instances are running and what hosts they're running on.

The adapter will then cross-reference that URL with its configuration information, and then it will identify the instance and forward the request onto that instance. That's a summary of the way that request works with the adapter. Now what I'd like to focus on with this slide is really that configuration information because that's really the entryway into your application architecture.

So this configuration information-- first of all, the information that the adapter holds is for three separate sets of information. First, its own configuration information-- for example, what load balancing mechanism that you want it to use. Second, it has a list of all available applications and 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 that are used to the pre-WebObjects 4.5 format, the PList. This configuration information that the WebObjects adapter has is obtained usually via a URL, and you configure that information in the web server configuration file. It's in the web server's configuration file that you configure your WebObjects 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 host list for the adapter, and it will actually contact these hosts for configuration information.

There's something I need to introduce here, and that's a process that we call WOTASC-D. This is new with WebObjects 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 two hosts, Helen and Telesto. And the WOTASC-D process is listening on port 1085. So what this means is that the WebObjects adapter is going to go and connect to Helen on port 1085, which will be the WOTASC-D process.

And that WOTASC-D process will return its XML information, its configuration information for that box. In this case, the adapter will combine the configuration information from two WOTASC-D 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.

So let's talk a little bit more about this Woe-tasty process. It probably spurred your curiosity. Again, as I mentioned, it runs on every WebObjects application server. It's very important. It started and restarted for robustness by a daemon called Woe-Service. That's on every platform. and his team have been working together to develop a new application for the WebObjects. The WebObjects is a software-based application, 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, its 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 WebObjects previous to 4.5, 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 WoTAScD process. And again, the WoTAScD process is local to that particular host. Monitor still exists, but it's merely just an interface to WoTAScD.

An interesting note about the WoTestD process is even though, let's say that you have your WoTestD process, you've gone in and configured various apps to run and communicate with WoTestD, WoTestD can still serve instances of your application that you have not configured with Monitor. When your applications start up, they send what's called a LifeBeat to Monitor to register with WoTestD. I'm sorry, it sends a LifeBeat to WoTestD to register with it so that WoTestD 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 for WoTestD 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 WOTASC-D, again on port 1085. You have your WebObjects adapter sitting there. You start up, let's say, four instances, two on each. They send their life beat to Wotesti, letting Wotesti know, "Hey, I'm ready to go." In your web server configuration file, you've configured a WebObjects 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 every 10 seconds with WoTAS-D on port 1085 and build this configuration information.

So now let's talk about this multicasting. It's similar to the host 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's light 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 you want to, you want to add another instance, let's say, to Europa and Callisto, another instance of your application.

But when those instances start up, they'll register with WOTAS-D via the Lifebeat. And guess what? WebObjects adapter will refresh its information every ten seconds. On the next refresh, the WOTAS-D process will alert the adapter to the other processes that you've started. So without you having to do anything with the WebObjects adapter, you've actually scaled your site seamlessly. So that's one of the advantages of the host list. Now let's talk about multicasting.

Multicasting is actually a network protocol. It uses an IP address from the administratively scoped domain. WebObjects has used this particular IP address that you see up here, 239.128.14.2. No need to memorize it, it's written down. I can't memorize those. Administratively scoped 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 WOTAS-D 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 resides, on which it is broadcast. But if you configure your router to pass on multicast packets, you can actually use this multicast to reach other subnets. That's an important point.

So WoTaskD, I'm sorry, so the adapter then, if it's set up to use the multicast, will then broadcast this multicast out on the network, and all WoTaskDs, because they register to listen for this multicast, will then register themselves with your WebObjects adapter. What this allows the adapter to do is build a dynamic host list. Now this broadcast, this multicast, is sent out by the WebObjects 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? 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 100 seconds or less.

Alright, so we'll get a little graphical representation of this. Again, we use Europa and Callisto, our WOTASd processes, and in the WebServer configuration file, we've configured a WebObjects adapter to use the multicast way of configuring it, of getting its configuration information. Start our instances. They register with WOTES-D with a life beat. We send out the multicast and dynamically build our host list. And then based on that host list, every 10 seconds, we'll query the hosts on that host list for the configuration information. All right.

So let's see. Sort of review. We know what our deployment architecture is, our three layers: presentation, application, and database. We've talked about the database adapter and the WebObjects adapter. Well, let's say that you get your site set up, and you go to hit your website for the first time.

You've configured, let's say, your adapter to use the multicast, you've got instances 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 of things we can do. First of all, we can actually query the WebObjects 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 Oberon, the path to the WebObjects adapter, cgibin/webobjects. We're actually sending the xyzzy command to the adapter.

How many of you are adventure fans? Anybody recognize that xyzzy? All right, good for you guys. Sort of dates some of the WebObjects 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 server is 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 there in pre WebObjects 4.5. Simply create a file named log WebObjects in the temp directory, restart your adapter, your HTTP server, and then your adapter will start logging out to a WebObjects.log file in the same directory. Make sure and turn that off when you're in deployment. Forgot to do that for QPromo. Learn the hard way on that. I'm so glad I didn't start with the store. All right, you can drastically reduce your performance.

Alright, so let's talk about this monitor. Let's sort of complete the picture. We know what WOTASC-D does. It's really the workhorse now as far as keeping your site up, communicating with your WebObjects adapter. Let's talk about Monitor. Well, it's a WebObjects application. It always has been. Again, it's the interface to WOTASC-D. 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 WebObjects adapter and tell it what, for example, again, what type of load balancing to use. And this is also password protected. Alright, so I'd like to introduce Melissa Turner. She's a WebObjects engineer on the WebObjects team. We'd like to demo monitor for you and show the interaction again between the adapter, Wotasty, and monitor. Am I? Yes, I'm connected. That was kind of important.

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. 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's demo at Macworld where you saw that a whole bunch? So I've added the host that's, as you can see, it's a Solaris box running backstage. We thought we'd show you that, yes, Solaris 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 of this application. We have a path wizard 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.

And this is a difference that some of you will notice between WebObjects 4.0 and WebObjects 4.5. Now you have to actually navigate down into the .wa and select the executable instead of simply selecting the .wa. 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've set up my defaults for the instance, so I'm going to go off and add an instance. I know I forgot something. And at this point, I want to show you, we talked about XYZZY. I want to show you what the adapter sees. This is the xyzzyy 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 Wotaski. You'll see that the application is running, and that 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 actually going through the web server. I'm not just hitting it through Direct Connect. This thing can be annoying. Yes, I'm an engineer. Therefore, demos must confuse me.

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 the various WebObjects stuff. It's just a little store application that lets you go buy things. I bought a PowerBook. 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 you. 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,

and for some reason it's not wanting to start well if it did want to start what I'd then show you is that I'd go back over to xyzzyy 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.

Alright, so we've talked about your deployment architecture, WoTASd, 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 WoTASd.

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, is 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.

Alright, 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 that 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 let's say on a static site, your pages, your HTML pages, reside on your HTTP server because they're publicly accessible. 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 we 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 a WebObjects 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 Q promo, it was my habit to just compile the application, copy the whole .woa folder, the folder with everything in it, and just copy it over to the document root of the HTTP server. Sold my images and stuff would get there. Well, they got there, but with 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.

from your resources on? KATHLEEN SULLIVAN: We, if you're-- this is sort of in the notion of troubleshooting. If for some reason you do your install, you have your app running, you're trying to hit it through the adapter, and your images aren't loading, it 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 troubleshoot problems. This goes to show, no 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 in deployment, for example. So we've provided a way with WebObjects 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 WebObjects. 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 defaults database called NSGlobalDomain, which allows you to have settings across multiple applications. So any settings in the NSGlobalDomain 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, as the programmer, you have ultimate power.

If you want to hard code something and make sure that it absolutely behaves a certain way, you don't want anybody changing the behavior, you can of course set it in code, which would then override anything that's presented on the command line or in the defaults 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 deployment. And let's say that actually you've put it in what I would call a staging area. You have your development area, your staging 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, bottlenecks to performance. And these are the 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 just way too much for that processor. You need to add a second processor or 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. If you don't have enough of it, it's going to start swapping to the database using virtual memory.

That swapping severely degrades your performance, so you don't want that to happen. How about the performance of the network? Your application is running fine, your database is fine, but the communication between the two is severely strained, so you need to increase your network bandwidth. These are areas that you want to focus on in looking for the problems.

The application in the database will be... bottlenecks will be talked about. I'll talk to you in great detail in the Optimizing Your Applications session, session 410. That's Thursday, I think. You want to look at that. The other three areas I'll address briefly. Really, the hard part of this situation, this performance problem, is in actually identifying with confidence where the problem is. The solution is usually more intuitive. 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 X, Linux, for example, for looking at your CPU and how it's performing, using PS or top. I like top especially because it's a dynamic update and you can actually have the columns sorting. So you can see what percentage of the processor you're using at any one point in time. UpTime tells you in three separate numbers what the ratio of the processes that your processor is using over 5, 10, and 15 seconds. That's also very useful to get just a quick snapshot of how your processor is doing.

How about monitoring your VM usage, the swapping that goes on? Well, there's VMstat or VM_stat, depending on which Unix platform you're on, to help look in great detail how the paging is doing and 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 how much 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 X Server comes with TCP dump. Packet sniffers are very useful at 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 netstat.

On NT and 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. Network Monitor comes with NTServer. It's a very useful tool. They have some great filters that help you sniff the lines and isolate different types of packets and different destination packets. So it's very useful.

Alright, 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've talked about together in a scenario. I'll sort of talk through how I might consider a sample deployment and what the thought process is that I might go through. So here's my setup to start with.

I have a few customers. My site is deployed, but maybe it's not very popular at the moment, so that's what the red circles are, 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 application. 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 two, my site may slow down, but it doesn't go down if one goes down.

So that's why I would have at least two on my site. And then, of course, Phobos is my database. You're always having that database. Alright, 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 that a little too soon, whoops, you don't want to hit that button.

I'm a bit concerned about the access that my users have directly to Europa. Actually, they could even talk to WoTAS-D directly, couldn't they, in this case, and get the XML configuration information. 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 in 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 WebObjects 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 Oberon2. And notice that it's also using the API adapter. Of course, I'm going to have to rename the first one to Oberon1 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 allow in packets on Oberon 1 and Oberon 2 through port 80, but then the user would have to choose which one to hit, and then it really wouldn't be scaling my site very well in a very intuitive fashion for the customer.

So I'm going to introduce something called Round Robin DNS. And 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 across your HTTP servers. Okay, great. Let's see what's next. All right, we get more servers. We're more popular. Things are going great.

And now Europa is having a hard time handling the traffic. Well, let's see. So that means we can't handle the traffic. So we can scale our application tier, and we're going to add Callisto and two more instances, of course, on Callisto for the same reason that I spoke of previously, always 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.

Alright, 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, oh, firewall, sorry. Alright, actually that's the wrong order. Let's see if we, alright, pretend the firewall didn't come up. Alright, so we have, what we want to do is have a second database come in.

And we'll call it DIMOS in this case, so Phobos and DIMOS. DIMOS is going to be a mirror of Phobos. Every insert, update, and delete that occurs in Phobos is going to occur in DIMOS so that they're identical at all times. And that way, if Phobos goes down, you can now write your applications with WebObjects for five to seamlessly connect to DIMOS and continue processing while your sysadmin is paged to look into why Phobos went down, get Phobos back up, get them back in sync, and then you're back in business again.

So it's a very flexible, scalable architecture across the three tiers. Now this 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 from my private resources. Again, it just makes things extra secure. You recall 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-- 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. And of course, separating it into your 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 haven't answered. And that is the now what. How many instances do I run? How do I know how much RAM? What should my architecture be? I think it's a big question. And about a year ago, I started-- 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-- it'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.

This isn't actually a Mac box. We're proving that we work on all systems. Actually, I'm going to talk a little bit more about troubleshooting stuff. You can, when you start an application, if you start it from a shell and start it with the command or the command line parameter, woe debugging enables, 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 Dirk, and there's a few things we've determined are kind of, sort of, they're the, you know, Stats? Measurements? They're the measurements that are important. These are the things that really sort of influence how many instances of your application you run.

Things like loop time, which is how much time does it take your application to run through the critical path of the incoming request. 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 to receive a page back? How many transactions is my site likely to be receiving per day? and sort of on the more WebObjects side, how long does it take for my sessions to time out? How big is my application when it has one session that's sort of gone through what we have deemed the sort of standard path through our site? How big is it when 10 sessions have gone through? How long are users likely to spend on any given page? And how many pages are they likely to hit during a visit? And 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 four seconds. And I don't know. Half a million transactions a day sounds reasonable for a brand new site, doesn't it? Think positive. And we'll set, you know, 30 minute timeout. We think people will be around for a while.

The initialized with one session is at 22 megabytes, with 10 sessions at 30 megabytes. And we think people will take about 20 seconds to look at each page, read over the stuff, and decide what they want to do from here. They'll probably hit, I don't know, 15 pages per visit.

We scroll down to the bottom, hit the calculate button, and it says, "Ooh, there's your results." It says 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 is six, as we said. This is some RAM calculations. Each session is going to take about 80 meg. Your application... 0.8. 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 21.2 meg. The average session length looks like it's going to be a little over 300 seconds. You'll deal with, you know, Sessions per hour. Yeah, I'm just trying to translate it into English. A little over 1,300 sessions per hour and you'll have, on average, 819 sessions active at any given time, which means you'll have about 778 megs worth of application at any given time. Over in this list, we sort show you what the maximum that this configuration can handle is likely to be, the maximum number of transactions per day, transactions per hour, you know, what the maximum session length is.

And when we calculate these numbers, it's done on a bell curve where we, or it's done by averaging out transactions over a day. We all know that there's likely to, the transactions are actually likely to be distributed on a bell curve, you know, California wakes up and the internet slows down type of thing.

So what you wanna do is you wanna make sure that your site, that 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's listed in this last column here.

What about the memory? And the memory, 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 three gigabytes of RAM on my website with six instances as long as my bell curve stayed below two million hits per day.

So what do you think? Yeah. That look good? Why don't you, why don't you click on the transaction per day hyperlink? So there's a glossary of all these terms, how I've calculated it, how we've 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 so we can modify it. And it's on your CD in your bag, your WebObjects demo 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, that was exciting. Public--it took a--really, it's been like about a year working on that. So again, it's in your CD--it's in your bag, and you can also download it from enterprise.apple.com at WWDC2000 if you don't get it there. All right, so roadmap. So where do we go from here? We covered a lot of material. There's a lot more for deployment. WebObjects optimization, Thursday at 9:00 AM. Maximizing performance and also performance metrics, I think, is very applicable to deployment because you've 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 BOF tomorrow night. Who to contact? Please send all deployment calculator information to Wode feedback, but there's also, in the introduction portion of the deployment calculator, there's information where to forward feedback on that as well, but you can forward it there.

and finally Q&A. 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, yes? Greek mythology. Greek mythology, very good. I'll accept that. But there are moons of the solar system.