Hi Nathan,
I am in agreement with all you have stated but this one caught my eye:
>Not with CGI.
Would you put together your own socket server that knew how to process
HTTP requests? I am guessing you would do that to eliminate overhead and
inadequacies in the ported Apache server?
Aaron Bartell
http://mowyourlawn.com
Nathan Andelin wrote:
From: john e
But if you want to build "facebook", then it would
not be a good idea to deploy on a "i'.
You made a lot of good points about the "i" being best for broadly scoped business applications and complex workloads, but I'll beg to differ about it NOT being good for simple applications like Facebook. Even Facebook needs a database. And regardless of your Web application architecture, when you're serving millions of requests, you'll need multiple database servers of the 64-way class.
So you could put your database on a Power server running IBM i, AIX, or Linux. Or you could go with a comparable server, running something like Oracle. Either way, you're talking about a big investment.
What makes IBM i better? First, the native environment is easier to manage. Second, the application would benefit from using RPG and record-level access.
Most architects today would go with a server farm to host the Web application, and go with a series of big Power servers to host the database. But what if one database server could handle database I/O and dynamically generate Web content about as efficiently as another could generate SQL result sets? Yes, I'm suggesting that you could do that with RPG under IBM i, and eliminate the server farm.
Not with CGI. Not with PHP. Not with Servlets. But it could be done by efficiently routing requests to RPG servers which would be performing DB I/O and generating browser content.
Nathan.
midrange.com
