I think to answer this question you need to convey the various workload
options we have to pick from.
Fair enough. On the IBM i platform, I generally think of workloads
pertaining to broadly-scoped ERP class systems which entail hundreds to
thousands of DB tables, views, etc., which may be manipulated, queried, and
maintained by thousands of procedures (call them functions or methods),
which are packaged into cohesive units (call them programs, service
programs, or classes), which are organized into functional areas (finance,
human resources, distribution, etc.).
On this list (Web400) I generally think of workloads which include HTTP,
FTP, SMTP, and any other protocols which use the Internet.
My point in beginning with that type of context is intended to suggest that
application architecture matters.
Another way to break down Web application workloads might include:
1. Handling HTTP requests which may include requests for dynamically
generated content in addition to static.
2. Dispatching requests to appropriate handlers, taking into account that
broadly-scoped systems would have thousands of handlers.
3. Parsing HTML forms, query string parameters, XML and JSON input, browser
cookies, environment variables.
4. Generating HTML stream files (reports).
5. Generating PDF stream files.
6. Merging DB data with HTML, XML, and JSON responses.
7. Generating HTML, XML, and JSON responses.
8. Running DB queries and stored procedures.
9. Performing DB transactions and basic updates.
10. Implementing data validation and data integrity constraints.
11. Implementing business rules (ie. updates to one table may trigger
updates to others).
12. Interactive I/O may trigger submits to longer-running batch work.
What is Node especially well suited for? It's gaining a good reputation as
an HTTP server, but what about responding to requests for static content?
midrange.com
