Disk operations - The cost of handling disk activity varies
between the architectures based on what, if any, circumstances cause
all request processing to stop while a disk operation is in progress.
In the MP and MT models, only the process or thread that causes the
disk activity is blocked. In AMPED, the helper processes are used to
perform the blocking disk actions, so while they are blocked, the
server process is still available to handle other requests. The extra
cost in the AMPED model is due to the inter-process communication
between the server and the helpers. In SPED, one process handles all
client interaction as well as disk activity, so all user-level
processing stops whenever any request requires disk activity.
Memory effects - The server's memory consumption affects the
space available for the filesystem cache. The SPED architecture has
small memory requirements, since it has only one process and one
stack. When compared to SPED, the MT model incurs some additional
memory consumption and kernel resources, proportional to the number of
threads employed (i.e., the maximal number of concurrently served HTTP
requests). AMPED's helper processes cause additional overhead, but
the helpers have small application-level memory demands and a helper
is needed only per concurrent disk operation, not for each
concurrently served HTTP request. The MP model incurs the cost of a
separate process per concurrently served HTTP request, which has
substantial memory and kernel overheads.
Disk utilization - The number of concurrent disk requests that a
server can generate affects whether it can benefit from multiple disks
and disk head scheduling. The MP/MT models can cause one disk request
per process/thread, while the AMPED model can generate one request per
helper. In contrast, since all user-level processing stops in the SPED
architecture whenever it accesses the disk, it can only generate one
disk request at a time. As a result, it cannot benefit from multiple
disks or disk head scheduling.