Hello. Day 3 and continuing. I wouldn't mind if you spell checked it :). I have the habit of just typing away and not going back and checking. Especially late at night.

Day started out with a MacOS X Kernel session. They went into Mach 3.0, the memory model, the task/thread model, the port model. MkLinux is an example of this working in action. Didn't take very good notes. Apple and CMU and OSF have some good literature about Mach. It appears Apple is more interested in making BSD the system interface API of choice with the movement towards pthreads and away from the mach cthread facilities. This will make it more compatible with the vast Unix world. Threads and handling of signals seem to be the largest differences between MacOS X and a validated POSIX system.

* Deploying WebObjects *

Most of the sessions I have been going to have either focused on WebObjects or Mac OS things. This session had a lot of common sense about deploying WebObjects on a production machine. WebObject team has spent a lot of time separating implementation and deployment. This makes scalability very easy with WebObjects since more machines, more server instances can be added and load scaling should be pretty graceful.

WebObjects high level general structure:

Web Server/httpd -- WO Adaptor -- | Web App (Server) Instances | Database System

This sessions focused on the potential bottlenecks in this configuration. WOAdaptor does a lot of load balancing work through a file called WebObjects.conf. This file contains a list of available machines and ports of Web Application Server instances available for processing client requests. The WOAdaptor manages the flow of requests. Currently, the two paradigms are random and round robin allocation of tasks coming in through the httpd. WO 4.5 will remove the WebObject.conf file with a move flexible proxy approach to load balancing requests across all available Web App instances.

A neat tool provided with the WO tools is the Monitor. This tool allows for interactive monitoring and control of WO processes. It can also generate the WebObjects.conf file for you. The Monitor can start and stop WO instances, record exceptions and gather performance statistics. One example of its use is in instance cycling. If your WO app code is not necessarily solid and contains a memory leak, Monitor can be used to observe the size of the memory taken up by each instance. If this is growing too much, Monitor allows you to either quit and restart the instance (clearing memory) or switch the instance to not accept any other client requests (gradually eliminating all connections being handled by the instance) and quit and restart after all client connections are complete.

There are a lot of potential performance concerns with WO. The database through their experience has been the most consistent reason for bottleneck. Of course bandwidth (between httpd and web apps or web apps and database), number of web app instances, RAM, CPU, etc. also impact the mix. As with any performance tuning, there are a lot of dimensions that might be the bottleneck for your app. WO allows you to record and playback events on the setup. One record some client event requests (average or abnormal web site browser requests) and this record can be continuously played, adding more client playback copies, to see how the performance of the system scales as more requests are made. Very useful for identifying performance bottlenecks.

SQL code might doing some unnecessary things. Setting a hard cap on the number of rows that can be retrieved will limit the network and processing impact of large, malformed client data requests.

There are also a lot of WO specific settings that can be adjusted. Most interesting is the claim single threaded instances will be better than multi threaded instances. This is more motivated by the difficulty of programming multithreaded apps. The need for locking of data access will usually minimize any speed up gained from multithreading the app. So, running single threaded instances on the app server might provide the best performance.

To check for disk paging, MacOS X Server vm_stat 5 should be below 500 faults. Otherwise, go get some more RAM. Network sniffer will be able to help identify the load on the network and any bottlenecks there.

Misc comments. As mentioned earlier, the WO adaptor will see some major changes in WO 4.5 when released. Monitor proxies on the web app side will be communicated with by the adaptor to manage system load balancing. Split install from a security standpoint. Make sure the deployed app and the web served folder are in different areas. Do not want the code or app to be accessible via the web. Direct actions are a added big optimization over WO 3.5. Separating static and dynamic content can save a lot of the load on the web app server.

As I hear more of the sessions, the system seems better and better. This sessions was probably more targeted for the big WO deployment sites (given the pricing as well I suppose). But it really showed some of the neat management features of WebObjects which separate it from the rest of the market.

* Metrowerks Key Note *

Not much in the way of new announcements. A nice thing is they are giving out Carbon/MacOS X development kits for CodeWarrior 4. So developers can get started. Carbon is shaping up to be a very smooth method of transition between MacOS 8.x and MacOS X. Apple is pushing for Carbon lib to be functional for 8.1 on up. Apps should be binary compatible across the two OSes. Of course a lot of the OS safety features (memory protection) and scheduling will not be available, but it just works as they like saying.

CodeWarrior is being billing as the biggest release since the initial CW so long ago. CW Pro 5 was demoed and some of the neater added features were shown off. They have been really working on the compiler and it is now on par with MrC. Their compiler can also be plugged into Project Builder in the MacOS X Server developer tool world. They have also spent a lot of time on the compiler and the debugging tools for AltiVec. Apple is making sure the tools are in place when the hardware starts arriving. They do not want a MMX situation on their hands.

CodeWarrior now consists of Core Pro5 IDE, Core Pro5 RAD plugins, and Pro5 Java RAD. Rad is the story of the day.They showed some quick examples of using wizards and automated tools to create a lot of the source code structure for you.

Debugging has been really improved. There is now the ability to remotely debug. Everything gets passed through the TCP/IP layer, even can debug on the same machine that way. gdb has been wrapped up and Metrowerks in MacOS X uses gdb to provide the same debugging environment everyone knows and loves in CW 4.

MacOS X developments. Carbon support will be shipping some time this summer/fall, prerelease version available today. Mach-O can host compile for other platforms. Nice plug into Project Builder if desired.

New IDE will import and export XML project files. This is moving the project file to a completely text format. Very cool for code management. Also Metrowerks API allows Perl scripting interaction.

PowerPlant 2.0 will have some nice features. Almost Carbonized. 1.9.x (_) is when it is released in CW 5 in June. PP adds object persistence, view architecture mechanism separate from frame and content, and unified messaging system with message objects.

Metrowerks is working hard to add features and functionality to save time for Mac developers. They are also getting a significant chunk of revenue from their embedded products. They mentioned the IBM/Nintendo PowerPC chip announcement so I assume they have some development planned for the future around that. They currently have Sega Dreamcast and Sony PlayStation II development capabilities.

* Apple Server Software *

Not much new. Apple is planning over time to merge the functionality that exists in AppleShareIP and MacOS X Server into one server release.

AppleShareIP has a lot of opportunities for 3rd party developers to provide more services and functionality. The IMAP administration on port 626 opens up a lot of potential improvements and additions. UAM and server side authentication and secure printing. API will be the same for MacOS X client.

MacOS X Server. Stressed NetBoot, QT Streaming, Apache, and WebObjects. NetBoot, they stressed Apple's commitment to provide higher power server given the additional need of power for the server machines. Given the SMP movements in MacOS X Server and X, might be one avenue this will arrive. QT Streaming, they are working on providing a plugin API along the lines of what is offered by Apache. This would allow for a lot of developer work to add to the functionality of the streaming server code. Should also be available across all platforms the code has been ported. Mentioned some developers have the code running on Linux. Scalability is going to be key. They mentioned the key note had 17,000 viewers dialing in, all handled from a ring of MacOS X Server boxes. Am not aware of the quality of the stream, but that is a lot of viewers. Maybe Victoria Secret should have thought twice about using Real Networks for their failed streaming event.

Apache, 3 million Internet sites, 60% of the web. WebObjects ...

Directory services are being improved. Plugins for NetInfo and LADP are planned for the future. Directory Access API will allow for other services to be provided. There is also the developing need for a Server Administration API which will allow for the management and monitoring of server events and status. In the works.

* FireWire In Depth *

Skipped over the FireWire after the Apple Server Software sessions completed. Missed the first half.

SBP-2 Expert is the current standard for handling FireWire device interactivity. Demoed example of the name directory working on the fly registering FireWire devices hot plugged into the system. SBP-2 Expert identified the device, loaded the correct driver, and one could observe a lot of other info available about the new device.

FireWire 3.0 (unsure of time frame) will be a major rev of the software. Will allow for _bootable_ FireWire devices. This implies minimal FireWire support will be moved into ROM and extensions (New World ROM) so the machine bootup process has enough FireWire disk driver logic to look on the disk for the correct driver to use. This will be neat. Unsure of what machines this will be available for (probably all those able to receive a ROM update). Need to add Open Firmware support.

Most of the current FireWire hard drives are ATA with a FireWire bridge chip inbetween. True FireWire devices will eventually provide cheaper chip logic and better performance. Must separate this approach from FireWire chip sets called Tailgate. This was an early attempt to tunnel the ATA traffic through the FireWire bus. This made the ATA interface go through the wire. This was scratched for the chipset bridges that translate the ATA interface into a FireWire interface to interact with other devices and machines on the bus. This allows devices to take advantages of the neat features of FireWire (vs. stuck in ATA land).

Something about AV/C and DV/mLAN devices. I think there needs to be some continued work on generic device driver interfaces. There are a lot of different potential devices out there and all of the interfaces are not clear yet for FireWire and how dynamic drivers will work in those cases.

3.0 will provide support for powered hubs. Power sharing will be flexible. 1394 open host controller interface chip will be changing from the first gen current chips from LSI. This will lead to better FireWire 400Mbps performance.

Lastly, some hints. Make sure any FireWire devices operate at 400Mbps. If some devices choose to interact at 100Mbps, they effectively act as speed traps for the rest of the system. Get vendor IDs from the IEEE so can recognize hardware when plugged into the FireWire bus. Make sure devices have unique serial numbers (try negotiating with two of the same devices with the same ID). Use 6 pin connectors. Apple will only sell products accepting/using 6 pin cords. Even if the 5-6 power pins are not used ... Use power off of the cord when possible. That is why it is there. Pretty technical session on FireWire. Apple will continue to push the functionality of FireWire forward with 3.0.

* Java on MacOS 8 *

Focus is on building Java into MacOS apps. JManager manages JavaVM, UI embedding and events and JNI. MRJ 2.1 added better JNI support/JNI objects, improved AWT, and JMApplet page APIs. JDirect is the Apple proprietary way of making calls to the MacOS toolbox. They stress this is a Apple only feature. They have been spending a lot of time creating a framework around the toolbox so it is "easy" using JDirect to call MacOS stuff ... And so on.

* Fine tuning WebObjects *

I got my fill of WebObjects performance today. There are lots of tools for performance profiling WO. For the System, use WOPlayback. For the Page, use WOStats. For the sub page granularity, use WOAssociationTiming. Memory, use objectalloc. SQL, use EOAdaptor hooks.

Lots of database specific speedups. Watch fetching, faulting and updates. Try to avoid I/O in some cases. Use primary key blocks. Do relationship caching. Result-set caching has some problems. Prefetching, and batch-faulting. Raw row fetching. Page processing. Small thing for user feedback perspective is to provide WOLongResponseTime, so people don't keep hitting submit over and over. Most of the session was for a demo by RSW software. They demoed their E-Tester, E-Load and E-Monitor tools for WO showing how events could be recorded and playbacked on the server to test the load capabilities.

Lined up for tomorrow will probably be an AltiVec session, BSD support in MacOS X, I/O Drivers in MacOS X (should be really interesting), Dev Tools for MacOS X and ...

Eric