Moto + Apache + Linux = The lowest operational cost per page view!
   
 


1. Native Compilation

When building a public Web Site or Web Application , the ability to deliver page views quickly and cheaply matters a great deal. Web applications should be designed to be distributed among multiple servers. But one System Administrator can only manage so many different machines. Thus the speed at which one machine can deliver page views matters.

Interpreted languages such as Cold Fusion can serve a complex dynamic page in roughly one second. That equates to 172,000 page views per day if traffic is evenly distributed. It's more likely to deliver 25,000 page views per day since normal usage patterns consist of spikes that push a server to its limits, and then flatten out completely during off hours. Technologies like bytecode compilation and just-in-time native compilation offered by JSPs and now PHP can reduce rendering time to around .1 second per page. That is, if the server doesn't require the database for each page view. Assuming normal traffic patterns that offers capacity for about 250,000 page views per day.

If an advertiser is willing to pay $1.00 per thousand page views, that box could earn $250 per day. Not bad, but in a year that $1.00 will more likely be ten 10 cents. Thus that server will no longer be paying its way. To go faster the application will need to be hardware native. That means it must be written against webserver APIs in C or C++.

Until now. With Moto, one can rapidly, iteratively, develop a web application just as in ColdFusion or ASP. Once functionally complete it can be natively compiled using the Moto Module Compiler (mmc).

mmc -n <module name> <path to moto files>  

The Moto Module Compiler converts .moto files into C files. It then dynamically generates an extra C file which implements the Apache module API. Finally, using open source tools included with Apache and most Linux distributions, mmc compiles all those files together into one, architecture native, dynamically loadable Apache module. The Module is dynamically loaded and run in process with the webserver at maximum speed.

[Mon Feb 5 10:37:25 2001] [info] cardlist.moto executed in , 0.004540 seconds. At this rate we could execute 220.264312 tps.
[Mon Feb 5 10:37:37 2001] [info] cardlist.moto executed in , 0.003121 seconds. At this rate we could execute 320.410123 tps.
[Mon Feb 5 10:37:42 2001] [info] cardlist.moto executed in , 0.003214 seconds. At this rate we could execute 311.138765 tps.
[Mon Feb 5 10:37:46 2001] [info] cardlist.moto executed in , 0.003084 seconds. At this rate we could execute 324.254219 tps.
[Mon Feb 5 10:37:51 2001] [info] cardlist.moto executed in , 0.002993 seconds. At this rate we could execute 334.112933 tps.
 

Maybe you don't need the speed a natively compiled moto module would give you. Consider these other benefits:

  1. The module can be distributed to other Apache users who lack the Moto development environment (since everything it needed was compiled in).
  2. Since the module is compiled, all the source code is hidden. Unlike apps written in Cold Fusion, ASP, or Perl, you need not transfer your source code to transfer your application.
  3. Since the compiled module implements Apache APIs directly there are no longer any third party dependencies, such as application servers, that need to be bought, installed, or managed.