Hi there, thanks for your thoughts on this. See my answers below in the text.
> On Jul 15, 2014, at 12:34 PM, Paul Dunkler <paul.dunk...@xyrality.com> wrote: > >> we are currently facing some deployment problems with >> WebObjects-Applications which most probably has the reasons in our (very >> big) running WebObjects-Configuration. >> While thinking about how we start fixing the problem, i faced the following >> question: >> >> Why is the complete SiteConfiguration of every application and every >> instance shared with every application server? > > I think it's about simplicity in the design. It syncs the SiteConfig.xml as > a whole as an independent task. Yes, but thats currently really a problem on one of our projects ;) For giving you an idea on what setup i am talking about: - 26MB SiteConfig.xml - ~200 Applications - ~15k configured / 2k running instances - 25 Application Servers (each 8-12 Cores, 60-120GB RAM) - 4 Web Servers - 2 Load Balancers - Some big Database Servers running on super fast ssds ;) >> I just checked the code of JavaMonitor. All default actions like >> addInstance, updateInstance and so on are sent to EVERY configured >> application host. >> And i'm wondering if it wouldn't be enough that every application server >> only knows about the instances configured to run on itself. > > This adds complication to the sync process within the concept of the > independent task idea. Yes, thats right - But maybe worth it when it speeds up the process by minimizing the SiteConfig.xml to the "interesting things for each host" >> Like its now the SiteConfiguration can grow very large. A synch-request >> which is triggered by the monitor in error cases is then taking a very long >> time to compute in the wotaskd which leads to configuration read problems in >> the adaptor. > > That's interesting, never seen that before. How large is your SiteConfig.xml > file, in bytes? > If you have one large SiteConfig files does it also mean you have one head > node? See below > A really fast, simple, error free network really helps. Don't go through your > ISP's network drops to communicate with your instance hosts, use a private > network switch. Giving JavaMonitor and wotaskd more RAM also helps a lot. We have our completely own managed infrastructure. Network is fine :) >> And then another thing. In the default implementation of the >> GracefulBouncer, the requests for updating scheduling and so on are only >> sent to the hosts which have instances configured for the current >> application. Why are these updates not sent to EVERY application server? > > Not sure if this is right. This information is stored in the siteconfig file > which every host gets. If a host does not get an updated siteconfig file, it > does do not get the updated schedule. You are right in the case that of every application one instance runs on every configured host. But not all of our applications have instances running / configured on all hosts. > I always treated all my hosts in a site exactly the same, including the head > node. I then turned on instances only on those that I needed - on the host > of my choosing. I never bothered to only place my application bits on those > instance hosts on which I told JavaMonitor to run an instance on. All hosts > got all the same bits - including the siteconfig file. Shifting traffic from > one host to another, temporarily if a host died, it's easier if all your > hosts have all the application installed. > > If your site configuration is indeed very large it may make sense to split up > your site. That whole 'eggs in one basket' thing. If your SiteConfig gets > hosed for some reason it can make the entire site behave wonky. > > Hope this helps. However I'm not sure I said anything you didn't already > know. :-) For now we are planning to split up the setup, that not more than 12 hosts and its instances are managed by one set of wotaskds. -- Mit freundlichen Grüßen / Kind regards Paul Dunkler
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
