WWDC2001 Session 611

Transcript

Kind: captions
Language: en
hi my name is Carl Hsu I am a web
objects engineer and just before we
begin I'd like to tell you that I don't
have any jokes I'm not funny I don't
sing I really can't play the guitar but
I am Canadian so welcome to session 611
this is deploying web objects
applications and this is really an
introduction to deploying a web objects
application we'll give a little overview
of how the deployment architecture of
web objects is structured we'll talk
about things that you can configure in
your deployment we'll talk about some
system monitoring tools we'll go over a
typical deployment and then we'll do Q&A
a so this is the typical deployment
architecture for web objects we start
with a browser which could be a web
browser or a java client or something
along those lines and it makes a TCP
request to an HTTP server a web server
that's known as the presentation layer
okay the web server then forwards the
request to your application your
application is the heart of web objects
it's your web objects application it's
what Ben's dynamic web pages back to the
client it's where all your logic is
that's your application layer the
application is dynamic and it serves
data it does things with data so usually
it talks to a database using UF that is
the database layer one thing to remember
is that when you deploy resources are
split between the web server and the
application itself so why do we do this
okay the first thing is that we want to
make public resources available easily
things like images sounds client-side
Java
that sort of thing and you want to make
those available because it's faster to
serve them through the web server than
it is to go through the web server to
your app and have your app serve it your
app should be only should only be
spending time on what it does best
your business logic the web server
should be doing what it does best which
is serving basically static objects out
so all the other things that your app
has the executable itself server-side
Java files which for web objects 5 is
everything pretty much components the EO
model file all that stuff should be
private it shouldn't be accessible
directly to a client ok and you want to
do this for a number of things again
security is probably the most obvious
one so that if somebody doesn't
accidentally get ahold of your yo model
or something along those lines if the
web server is badly configured and this
is known as a split install because you
take the resources you divide them into
public and private and you install them
in two different places so let's talk
about deployment configurations what are
the supported deployment platforms for
web objects Mac OS 10 server the new one
Windows 2000 Solaris 2.8 Mac OS 10
server comes with a Java runtime 1.3
Windows 2000 Solaris 2.8 we require that
a JRE of 1.3 or higher already be
installed
what sort of hardware should you run on
what kind of processor how fast how many
how much memory how much disk space
whether you have more than one machine
where is the server located network how
fast is it how secure is it what about
the physical security of your machines
what about the temperature of the room
the machines are in UPS's that's
particularly important if you're in
California
software it's important to know what
kind of account your applications will
be running on you could run them all
with this route this may not be a good
idea to let your you know to have
unrestricted access to your filesystem
and the rest of everything
what about application logging you're
deploying an application you need to be
able to figure out what's wrong if
something breaks what about access
control who has access to the
application who's allowed to configure
things these are all things that you
really want to think about so we're
going to talk about what can we control
the areas that we're going to talk about
today and it's this deployment dependent
and typically the things that you can
tweak or control are the web objects
adapter the application itself and the
database
well tweaking the database is really
something that's an entire profession
unto itself so we're really not going to
go into that here we're gonna talk about
the web objects adapter and the
application so what is the web objects
adapter we saw the deployment
architecture from before and the web
objects adapter is what Ford's the
request from the web server to your
application what does it do for you why
do you want to do this rather than just
having a client connect directly to your
application it gives you better
performance
it lets you load balance it between
multiple instances and it provides other
things such as pooled connections etc it
validates client requests a nice thing
about the adapters is that it can do
some things with cookies to help you
validate sessions it can also validate
that it's a well-formed request so that
your application doesn't have to deal
with badly formed requests that may be
designed specifically to crash the app
or even accidentally and it's more
secure not giving people direct access
to your applications makes things a
little bit nicer for system
administrators it also separates things
out so that the only contact that people
have with the outside world happens to
be your web server so there are two
types of web objects applicate web
objects adapters
the CGI adapter common gateway interface
and the API adapters which are plug-in
modules why would you want to use one of
the other CGI works anywhere all of our
supported platforms probably on some
that aren't but it's slow every time a
client makes a request you have to fork
a new process and it doesn't support
load balancing on some platforms windows
in particular VAP on the adapters are
plugins we have plug-ins for Apache ans
API which is for netscape's I planet and
is API which is for Microsoft Internet
Information server they're fast but they
can only be used with those specific web
servers and only on specific platforms
their major advantage is that all of the
API modules support load balancing and
we'll talk about load balancing in just
a second all of the web objects adapters
are written in C we provide the source
code so that you can modify them you can
adapt them you can tweak them if you
make them better tell us and hopefully
we'll incorporate the changes which
adaptors do we support if you can see on
all three of our supported platforms CGI
works with pretty much everything on OS
we support oh I'm sorry this is slides
been modified so on OS 10 we only
support Apache we do not support NS API
on Solaris we support Apache and NS API
on Windows 2000 we support NS API and is
API so just in case y'all are taking
notes we do not support NS API on OS 10
so let's go back to an earlier slide
what's load balancing I talked about it
this is really a performance thing this
is a big performance win for you in your
applications what it does is it
distributes client requests between
multiple instances of your application
why would you want to do this because
even though you're slowing down a little
bit the actual transit time because you
to pass the request through in any
immediate your app is doing all the work
your app is doing all of your logic it's
dealing with the EOS it may be doing
enormous amounts of work against the
database and so even though the the cost
of passing requests to the application
and back from the application is
negligible so the idea is to have more
applications you can have multiple
machines with multiple applications
running on them they do all the work and
all the adapter does is pass requests
between them because of the way that web
objects deals with sessions we only load
balanced requests that don't have a
session once you have a session you're
typically assigned to a particular
instance running on a particular machine
and you'll stay there until the session
is gone there are three types of load
balancing there's random and in random
the adapter basically for a new request
just picks and arbitrary instance
round-robin where the adapter will pick
the instances in the sequence if you had
three instances it would go one two
three one two three are you feeling
sleepy yet load average tries to pick
the instance that has the least number
of sessions there's it's a slightly
tweaked heuristic but essentially that's
what it boils down to let's take a look
at the adapter overview what happens
specifically well the browser makes a
request the web server will pass it to
the web objects adapter and the web
objects adapter will look at the status
request line the URL that the browser
requested and in this case we see look
it's requesting the application killer
app okay and if you can see killer app
dot Walla / - the - indicates that we're
looking at instance two we probably have
an existing session on that so the
adapter has a sort of a map and it says
killer app - it's tied is located on the
host Quaglia and it's running on tcp/ip
port 4000 - so it's found that it then
forwards the request to your application
the application will process the request
returned the response to the adapter the
adapter hands it back up to the web
server the web server hands it off to
your client and we're off the adapter
site configuration so I alluded to a
mapping that's the adapter site
configuration and what it is is it Maps
an application number name and an
instance ID to the application server
and the tcp/ip port that that instance
happens to be running on so I'll just
give you the examples from before killer
app 1 running on the host Quaglia port
4001 the site configuration also has
some additional information what kind of
load balancing you should use for this
particular application the number of
persistent connections to make to that
application tcp/ip sockets that sort of
thing there are three ways that the
adapter gets this configuration
information the first way is from a flat
file basically it'll just read a file
off of the disk the second way is a host
list
it'll get dynamic data about application
instances from a series of hosts that
known hosts that you pass it and
multicast which is sort of a broadcast
mechanism for discovering what hosts are
available we'll go through these one by
one in just a second the configurations
for these are updated every 10 seconds
so every 10 seconds the adapter will
check to make sure that instances
haven't left or new instances haven't
been added or new applications whatever
so let's look at flat file flat file is
in an XML format and the DTD that
defines it is in the documentation it's
also I believe in the adapter source
code that we provide so we give an
example and it's pretty simple I mean we
have an application named killer app
it's being scheduled using round robin
and it has one instance with an ID of 1
running on qualia port 4001 host list
configuration
so again this requests dynamic
configuration information from a list of
hosts the information is normally
supplied by something called the web
objects task daemon or boat asti for
short
this will caste daemon runs on each
application server or a host the
information that will tast e supplies to
the adapter upon request is in the same
XML format that the flat file requested
the flat file file uses and the reason
you want to do this is because it allows
for really easy dynamic addition of
application instances on a set of known
hosts this is also the default mechanism
that the adapters use the adapters are
pointed at the local host by default so
you'll see 1085 come up probably 1085 is
the port that what asti is running on by
default and that's where the adapter
requests information that's the port
that the audacity will return
information on so we'll take a quick
look at how this works
what has T is running on the two hosts
Quaglia and ploy cout four instances are
started and they register with low caste
so that what asti knows that they're
running in the meantime the adapter has
this pre-configured host list to look at
these two hosts and what it'll do is
it'll send a request to the two hosts
and ask them for configuration
information and from that it'll generate
its site config what it does is it
actually will merge the xml returned by
the various Matassa T's into a complete
list so let's talk about multicast
really quick multicast is kind of
interesting what we do is we broadcast a
UDP packet a request to a specific IP
address and a TCP IP port we broadcast
it to a multicast address and what that
address does is it sends it by default
to every machine on your subnet you can
configure routers to pass it beyond that
but in general that's how routers are
configured by default to stop the
packets at the subnet and what happens
is all the low caste
that are running and listening for that
broadcast will respond this allows us to
dynamically build a list of hosts once
you have the list configuration proceeds
exactly like host list did and we look
we do this broadcast about once every
100 seconds because we don't really want
to be doing this all the time so how
does multicast work same thing we had
before we had the two hosts with what a
sneeze running on them and the web
objects adapter pre-configured to look
or rather to send on that multicast
address applications start and register
with what asti the web objects adapter
will then broadcast get the responses
from quale employ cout and build our
dynamic host list and finally it does
what it did in hosts list which is to
send the request directly to the known
hosts get back the reply and generate
the Sai config so I alluded again to the
web objects Testament boot asti let's
talk about this really quick what has T
is a web objects daemon that started at
boot time on Mac OS 10 and Solaris and
at login time on Windows 2000 it's
watched over by another daemon process
so that if what has T dies it should be
restarted and that way if what asti dies
you don't suddenly lose an entire host
and nobody can connect to it and its
major job is to supply the adapter with
that xml dynamic configuration data and
again it does this on port 1085 by
default to do this it registers running
instances on the same machine the other
thing that it's allowed to do is that it
will monitor and cycle and restart
configured instances on that machine so
how do we get it to do all this well
what asset e is configured using an
application called Java Monitor Java
monitor is a web objects application and
its major purpose is to provide it a web
interface for what a steam you can use
it to configure individual application
instances or entire applications
you can use it to manage multiple hosts
you can use it to configure the web
objects adapter and finally you use it
to set up scheduling for instances Java
monitor can be password protected but is
not by default and it has a new
interface in web objects 5 before we
gone I wanted to mention something about
instance scheduling the idea behind
instance scheduling is that a scheduled
instance is restarted periodically by
what asti so after a certain period of
time wood has tea will tell an instance
that it should shut down and when it has
it'll start start up a new instance of
it you want to do this in case you're
expecting to bring them down so that you
can put up a new drop of the instance if
you have known memory leaks anything
along those lines new in web objects 5
is that each instance can be scheduled
independently rather than grouping and
scheduling by an application so we have
three types of scheduling we have hourly
where you can reboot the application
every X number of hours 2 hours 4 hours
daily where an application will get
rebooted every day in a particular time
and weekly where an application will be
rebooted every week in a particular time
and we can terminate instances
immediately where it'll just exit or
gracefully where we set something called
refused new sessions and what will
happen is that instance will stop
accepting new user requests but will
continue processing existing user
requests once all of the existing users
are finished then it allows it and start
over this is nice because you don't kick
users off the plateau off of their
session so let's take a look at Java
monitor and I'd like to ask Josh Behnke
to come up and do a demo
[Applause]
so he's not wired with the mic so he
doesn't joke or sing or dance either
alright so this is the first screen that
you should be presented with when you
start java monitor and because we're
gonna use it later on let's go to the
site tab and what we're gonna do is set
the URL for the adapter and we're really
doing this this doesn't actually choose
which adapter you're using you can have
one or many adapters and you can switch
them on the fly to point to different
instances but this is what we use to
generate URLs all right so let's add the
host so in this case the webserver and
Java monitor are running on the same
host and we'll add this host if you can
see we have three different types of
hosts Mac OS 10 Windows and UNIX you can
choose the type of host that that
happens to be and we'll add it one of
the things that's useful for debugging
for seeing what's going on if you're
having trouble is under available it's
now a hyperlink so if you click on yes
you get a bunch of information about
that particular host you have the site
configuration as it's written to disk
the adapter configuration as it's being
sent back to the adapters by request and
all the way at the bottom you just have
some information about what what asti
thinks is going on all right so let's
add an application we're gonna add an
application hello world ok we're gonna
name it hello this doesn't this name in
monitor doesn't need to match the name
of your application proper the this is
so that you can have multiple sets of an
applications scheduled independently
through the adapter so we're gonna get
the path to the application and we'll
use the path wizard here we select a
host and then we navigate it's in
developer examples Java web objects
leave hello world hello world whoa whoa
one thing to note there's some confusion
in the past you have to select the
executable inside of the watch just
selecting the woma isn't good enough all
right one thing we're going to do is
turn off
to recover autorecover is the setting
that says to monitor if this application
instance dies restart it automatically
don't wait for me to tell you or
anything just started as soon as you can
and we're going to turn that off because
we're going to do something with the
demo later so let's go to the detail
view and this is the page where you will
actually end up doing most of your
monitoring we're going to add two
instances to the hosts that we've just
added okay and we'll start them so this
page by default refreshes every 60
seconds you can either turn that off or
you can set it to a different number
depending on how you want it to go and
you can start and stop instances
independently as a group you can turn on
and off auto recover independently as a
group same thing with refused new
sessions and you can turn off and on
scheduling from here as well once the
application is running we show some
basic statistics
number of transactions number of active
sessions some timing statistics we also
keep track of how many times the
application is died so that you know
when it's dydz because if you have auto
recover on you may just look at it and
be oh my application is still there but
it might have died every ten minutes for
the last hour the whoa stats link is
basically a link to the applications
view of its own statistics they're
fairly detailed okay so if we refresh
the page hopefully the instances are
alive at this point in the are so the
hello at the top is a link through the
web server adapter to those instances as
we can see we have hello world alright
we've already split installed hello
world into the web server document root
so we get images and that sort of thing
normally you would either copy them in
manually or you could I believe you can
modify project builders so that it'll
install them for you okay excuse me
so what we're gonna do now is we're
gonna show you about multicast the web
server right now is configured by
default it only looks at the localhost
all right and we can actually prove this
Josh if you could go to the wou adapter
info page okay so this is the what would
after info page and what it is is a view
into the state of the adapter at the
moment we have links to existing
applications as well as information and
if you see this line we're only looking
at
we've only got that one host that we're
looking at we also have a bunch of
configuration information about the
adapter itself so what we're gonna do is
we're gonna go back and we're gonna add
a second host and that's our second demo
machine and then we'll go and we'll add
two instances to that host
so what will happen at this point is
we've added this host but the host that
we've added isn't on the known list of
hosts that the adapter knows about and
what will happen is even though these
instances are there the adapter won't
see them and we'll fix that using
multicast so let's refresh and see okay
so you see that the adapter really
doesn't know about them monitor if you
refresh should know about them there you
go
so you the applications are running the
adapter doesn't see it so what we're
gonna do is we're going to stop the
webserver and edit the configuration
file and we're going to change it from
looking at the localhost only to doing a
multicast broadcast
okay
and we'll start the adapter back up and
we'll see what we get
and there we go so all four applications
are now showing and what you can do at
this point is just keep adding hosts on
the subnet the adapter will just keep
picking up hosts and picking up whatever
instances happen to be running on those
at the same time so one of the things
we're gonna do is show we're just gonna
show shutting down an instance and
watching the adapter pick that up
so let's shut down instance one give it
a few seconds refresh sometimes the
timings not quite right
so that monitor knows that it's dead and
it happened immediately we refreshed
that means that the adapter knows about
it immediately but what happens if an
application crashes if an application
dies so Josh can we go to the command
line and kill whatever our most recent
thing happens to be okay so this gives
me a chance to segue into life beats how
does the what have see on a particular
machine know then an instance is alive
well the instance sends life beats
tcp/ip life beats to load a ste and it
tells it I'm alive I'm still here it
does it about every 30 seconds and what
happens is when you shut down an
instance you either terminate it
internally by calling terminate or you
send a shutdown through monitor the
instance knows it's going to shut down
so it sends a special life beat to loot
asti that says I'm shutting down right
now if it doesn't what asti has to wait
until it's decided that the instance
really isn't alive because it hasn't
responded for some period of time so in
the meantime what we'll do is we'll take
a look at failover we can try to connect
to instance two which is what we just
killed directly and you click on it and
somehow we've come up with hello world
even though we've killed it but there's
actually something interesting going on
if we type in a name and we hit enter
and you can see that we're actually on
instance three we're not on instance two
anymore so the adapter tries to be smart
about it if your instance if the
instance you specifically request
it is dead you'll move to a different
instance I believe the XML sessions
showed that if you have a persistent
session story you can do some really
interesting fallback failover mechanisms
with that so we refresh the monitor page
okay so monitor has decided that it's
dead and at this point the adapter
should be able to pick it up and it's
also dead okay so that was just a quick
demo of monitor and what Asti and how to
do a very very basic deployment we go
back to slides so the adapter info page
is actually really important the adapter
info page is accessed the same way you
would normally access a web objects
application but instead you use the
application name low adapter info this
is really good it provides a lot of
information about how the adapter
happens to be configured you can see
which hosts it's looking at which
instances it knows about what the
settings for various timeout options are
set to it provides links direct links
for all of those available instances and
that's really useful if you have an
instance started and you don't know
where it is
that adapter info page will tell you
it's disabled by default for security
reasons we had it enabled during the
demo you can either password protect it
or you can have it for public access
during the demo we had it for public
access what will happen is in fact any
unknown name application name will cause
it to come up we don't suggest you
deploy like that but it's useful for
development the other thing for looking
into how the adapter is working is
adapter logging you create a file named
log web objects spelled just like that
in the temp directory of your system so
C colon backslash temp I think on
Windows or slash temp on UNIX systems
and what will happen is long file named
web.xml
to it logging is slow and so what we do
is we allow you to start and stop it
without restarting the web server you
can have your web server and the adapter
running and you just create the file in
a few seconds later we'll start logging
to it when you delete log web objects
will stop logging to it okay so now
we're moving on we've talked about the
adapter and how it gets its
configuration we're going to talk about
configuring instances so those of you
who went to the moving for two web
objects five session know that instead
of the defaults database which we used
to have we now do configuration using
standard Java util properties and very
roughly from our point of view we see
the properties file from all your
included frameworks the properties file
from your application itself and then
command-line arguments in that order of
precedence so the properties file is
named properties and it's located in the
resources directory of your boa or your
framework and it's in pretty standard
Java format you multiple lines each line
is key equal value you can also pass
command-line arguments and those are
passed this dash D property name equal
property value again we also support the
old method of passing arguments to web
objects which is the - whoa debugging
enabled space yes or true and that works
as well but is deprecated so what are
some useful deployment properties for
configuring an application we have well
port will host whoa debugging enabled
will output path will cache enabled
we'll listen queue size will allows
concurrent request handling will work
our thread count min and Max some of
these are new some of these are old so
what port forces the application to
listen on a specific tcp/ip port if you
don't set it it'll just ask the system
to choose one which is why you typically
get if you start an application from the
command line you get ports that are like
fifty seven thousand something woah host
is new and you pass it either an IP
address or a host name that has dns
resolution and what it'll do is bind
that application
to a specific IP a specific interface
this is really useful if you have a host
that happens to have multiple IP
addresses you have to two Ethernet cards
in a machine one pointing one direction
and one pointing the other direction and
you can't figure out why your
application happens to bind to the wrong
one and no one can see it this is what
you would use you would bind to a
particular address and all the requests
will forward to that one if you don't we
just default to grabbing the first host
name that we find this isn't necessarily
consistent it sort of depends on the
Java platform there's some support for
logging now so though it's whoa
debugging enabled and you turn on and
off basic web objects logging there's
also I think a Oh adapter debug enabled
and some other stuff really C NS log for
details it's best that you can customize
this for your particular application by
enabling or disabling specific debugging
groups and it's specific debugging
little levels in any case what we
provide now is whoa output path whoa
output path redirects all of your
debugging output from NS log to a
particular file normally we dump it all
to standard out in standard error this
lets you this lets you set up instances
in monitor and have the output
redirected to independent files rather
than having them all mashed into well
used to be mashed into the wrote a steal
output and now in Java doesn't go
anywhere so now we're on to performance
properties low caching enables this
tells the web objects application
whether or not it should cache the web
objects components in memory basically
the dot whoa files by default for
deployment installs it's true and it's
false for development so in development
you should be able to tweak HTML and the
next time you hit that page it'll show
up for deployment for speed reasons we
don't check every time the listen queue
size is the number of outstanding
requests at any given time so your
application may end up having a lot of
long running
Quest's all at once and it doesn't have
any resources available to process new
requests when that happens things start
piling up in the server socket and the
bolus and queue size lets you set how
many connections we allow to sort of
wait to get accepted
whoa allows concurrent request handling
is a little touchy what it does is
determine whether or not requests are
processed in serial so by default we
will read requests from sockets and
write responses out to sockets in
parallel we can have dozens or hundreds
of threads doing that at once but all
the requests are processed one after
another and the reason we do this is
because it's safer in order to do in
order if you set this to true your all
of your code all of the code that you
access and call must be thread safe if
not bad things will happen so the last
thing is what worker thread count-- man
and will worker thread count Max and
this is just the number of threads well
worker thread count is the number of
threads that we use to process incoming
requests we start at 16 we default to
grow to 256 you can allow to grow
infinitely for those of you who familiar
with four five or four or five one we've
changed this a little bit the number of
threads used to be set we try to take
advantage of Java's heavy threading
model and rather than pooling threads we
simply have a number of them waiting and
accept which if anybody went to the Java
performance session works really well
alright so what are potential
bottlenecks that we should you should
look at when you're doing a deployment
the application logic itself could be a
bottleneck you could be doing something
amazingly stupid sorting of 40,000
element array using bubble sort you
could be using the wrong database
wondering why despite the fact that you
have hundreds of connections doing you
know dozens of megabytes worth of
transaction processing why isn't it
working until somebody points out that
you're using the flat file adapter
what kind of CPU well hey we're running
say my big honking story calm on a
cellar sometimes it's not a good idea
you own a big CPU if you can get it you
want more because of the threading the
heavy threading that we have now them
will take as much advantage of multiple
CPUs as you can reasonably get do you
have enough memory please
swapping is bad I'm sure you've heard
this but really swapping is really bad
ok Network you want a fast Network in
particular I mean you can't really
control the network to your clients
because that's up to them but you can
control how big of a pipe you've got
between your application server and your
web server and you really want that to
be big we make a lot of assumptions that
you have an essentially unlimited pipe
between the two because you should
alright so if you're interested you
should see optimizing web objects
applications I think that's coming up on
Friday and they'll talk about
specifically how to look at your
application itself so let's talk about
the system's then so how do I tell how
much memory or CPU I'm using on Mac OS
10 there's the CPU monitor there's the
process viewer and vmstat the image
that's a command line thing it'll tell
you basically how you're paging how many
pages you've got free how many swapped
out locality or that sort of thing CPU
monitor tells you how much CPU you're
using in process viewer lets you view
processes so Solaris says PS and top PS
is basically a process listing and top
will give you sort of an overview of how
your system is behaving at the
particular time Windows has the task
manager which sort of does a number of
different things it's both the process
viewer and a CPU monitor as well network
monitoring tools Mac os10 has the
network utility lets you do things like
net stat and ping and that sort of thing
Solaris says the net stat directly at
the command line and Windows as a
Network Monitor driver for its
networking stack all of these basically
try to let you see what sockets are open
on your system are we
are they doing good do we have too many
open and then you have packet sniffers
give them in hardware you have them in
software and they basically let you
actually look at exactly what's going
across the wire between you and clients
between the app server and the web
server and sometimes you find out really
interesting things so this is going to
be covered in optimizing but I wanted to
touch on it really quick application
monitoring tools we're now in pure Java
and one of the big big advantages of
being in pure Java is that we can now
use third-party tools you can use je
probe optimize it optimize it is now
available on Mac OS 10 the job of
performance team uses it and that's
really great Objective C sort of had
this problem of looking into the code we
have any number of profilers things that
will instrument all sorts of stuff now
you have external load generators we
ship with playback manager and the
playback client and they basically just
you record a set of actions and it'll
play it back silk performer is a third
party product that does something very
similar these are good for determining
your actual real world performance it
can say how many requests hit your
application and see this is really good
for seeing specifically what's going on
how does the application perform overall
rather than at a very small detailed
level and finally the web objects
frameworks themselves provide some sort
of feedback
there's the whoa event stuff which will
be gone over in detail and optimizing
web objects and the most stats page
which you can access from monitor and
that'll give you statistics on which
components were called the average
transaction time for that particular
component how long did it take that sort
of thing so let's take a quick look at a
typical deployment and the thing I
remember is we're going to try to show
that all the deployment principles are
the same it doesn't matter whether
you're a small home-based application
going over a DSL a mid-sized small
business app going over part of a t1 or
ISDN or a large enterprise app going
over multiple T ones all the deployment
principles are the same web objects
doesn't really distinguish between them
and systems monitoring doesn't really
change so we start with a very simple
deployment you have a small number of
applications they go to your web server
Mathilda in this case and they pass
requests to quality which is talking to
a database cabby so one of the things we
start by doing is adding a little bit of
security so that people don't have free
access to your web server we add a
firewall we only allow requests to
Matilda 80 to pass through but then the
number of clients grows and we do some
monitoring and we discover that it's
actually the web server that's at fault
this time it's unusual but it does
happen so we add a second web server and
we round robin DNS them so that requests
get passed between the various web
servers and they all talk to the same
set of instances we do a little bit more
monitoring the number of as the number
of clients grows and we discover all
right so our web servers are holding up
pretty well now our bottleneck happens
to be the application the application we
don't have enough instances so we add a
second instance or sorry two more
instances on another host and a lot of
people will do this at this point it may
be worth it to set up another firewall
so that requests between the web server
and the application instances also have
to pass through a firewall and that's
also for security so finally maybe the
database all the way at the end is what
your final bottleneck is and you may
have a Mara database so that you can get
data out faster so it's important to
note that what these firewalls that
we've set up as we've grown in this
particular deployment is it separates us
there's the intranet zone all the way on
one side or the internet zone and that's
totally insecure people can do whatever
they want on the other end we have our
completely private network and this is
where all of your value is all of your
data all of your logic everything
important to you is on the far right and
we have sort of like a DMZ border zone
in between and
again this is why that split install
that split of public and private
resources is important so that the only
things in that border zone aren't that
important they're just public stuff the
things that people should be able to get
anyway so that's pretty much an overview
of how web objects deployment works you
can have multiple instances and
potentially multiple application servers
and you have a web objects adapter and
the web objects adapter passes requests
to the ER instances and it can do that
in a number of different ways the
instances will process and return it we
have a number of mechanisms available
for you to tweak and we provide tools so
that you can deploy and hopefully have a
nice deployment and that's it okay
thank you so the web objects lab is
still open it's open from actually when
this session started to 6:00 p.m. today
and tomorrow for some limited hours so
be warned about the limited hours don't
wait until 4 o'clock tomorrow because
it's not gonna be able then we have a
road map and it may seem a little
strange that we want you to go to the
java performance because even though
that was yesterday but you should all be
getting DVDs this year sooner and when
you do that's certainly something to
look up to because try to take advantage
of the language try to take advantage of
all the work that's being done on the
job of EMS optimizing web objects
applications specifically is tomorrow at
2:00 and then of course if you have any
comments or questions about deployment
or anything else please come to the
feedback forum on Friday this is I'm
sure you've seen this slide before this
is who to contact
Tony Bob I services URLs
you