计算机－＞网络

FD_SETSIZE在不同操作系统中的行为(From Squid)

Diviner — Wed, 26 Jul 2006 09:56:00 GMT

1、LINUX下面
Cannot increase FD_SETSIZE on Linux, but we can increase __FD_SETSIZE
with glibc 2.2 (or later? remains to be seen). We do this by including
bits/types.h which defines __FD_SETSIZE first, then we redefine
__FD_SETSIZE. Ofcourse a user program may NEVER include bits/whatever.h
directly, so this is a dirty hack!

#if (__GLIBC__ > 2) || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 2)
#include <bits/types.h>
#undef __FD_SETSIZE
#define __FD_SETSIZE SQUID_MAXFD
#endif

2、FreeBsd

Cannot increase FD_SETSIZE on FreeBSD before 2.2.0, causes select(2)
to return EINVAL.

3、Mac OS X Server

Trying to redefine CHANGE_FD_SETSIZE causes a slew of warnings
on Mac OS X Server.

其他的大部分平台基本上都可以重定义FD_SETSIZE（当然包括winnt系列了)

提供ACE(主要是proactor)、网络编程部分的咨询。

Diviner — Wed, 12 Apr 2006 00:55:00 GMT

转：15,000 Simultaneous Connections

Diviner — Sun, 15 Jan 2006 03:00:00 GMT

Lincoln Dale wrote:
> in order to be able to handle large numbers of concurrent connections (open
> sockets), there are really only two ways of doing it efficiently:
>
> (1) single process using threads
> (2) single process, event-driven queues
>
> with (1), you have a slightly higher overhead than a well-written (2),
> however you can scale to multiprocessor with no additional effort.
>
> (2) will always be best, but is typically one of the hardest to code for.
>

Whether (2) is best or not depends upon the kernel interface. If a
scan of 15,000 file descriptors is required for each event (such as
a straightforward design based on select()) then (2) could be nearly
as bad as a naive accept()/fork() model, while a thread-per-connection
model might scale better. If the kernel somehow passed an event list
to the server process more efficiently than via select() or poll(),
then I would agree that (2) is probably always the better way, perhaps
with extensions into a thread-per-processor regime on SMP's.

Achieving the best efficiency involves coupling the arrival of a packet
to the object (explicit or implicit) handling that particular connection
in the most direct way possible, modulo buffering. Eliminating linear
searches from that coupling is important--a scan of 15,000 descriptors
is going to be a significant hit, no matter what other efficiencies are
involved, since it is O(n^2) (where n is the number of connections). This
is why a threaded model might work better for large numbers of connections,
assuming that thread scheduling is better than O(n^2). (Is it?)

I've actually implemented high-efficiency servers based on a combination
of (1) and (2); in essence, a small pool of threads each handling a number
of connections using an event-based model. At least for my project (which
involved high connection rates more than large numbers of sustained
connections), one or two threads per processor seemed to be the most
efficient configuration--but this was under Solaris, not Linux, though
I certainly was able to achieve good performance (>1000 connects/second
on a UP P2/333) on the latter in tests.

Just another data point.

-Ed

ICE，你真的比CORBA要快吗？(转NEWGROUP上的贴子)

Diviner — Tue, 03 Jan 2006 11:47:00 GMT

omniORB and Ice performance compared

关于此主题的全部 7 个帖子 - 树式浏览

Duncan Grisby

2005年11月22日下午8时12分显示选项

新闻论坛：comp.object.corba

发件人： Duncan Grisby <duncan-n...@grisby.org> - 查找此作者的帖子

日期：Tue, 22 Nov 2005 12:12:55 GMT

当地时间：2005年11月22日(星期二) 下午8时12分

主题：omniORB and Ice performance compared

Hi,

At the risk of further fanning the flamewar, I thought I would do some
performance comparisons between Ice and omniORB. ZeroC make a big deal
out of Ice's performance -- it's mentioned before anything else in the
description of Ice on the ZeroC web site -- so it's good to see how it
really performs. I don't want to imply that performance is the only
important thing -- whether Ice is better or worse than CORBA in other
respects is a separate issue.

To do the comparison, I used the latency and throughput demos from the
Ice distribution. It didn't take much modification to turn them into
CORBA programs.

The performance tests were done on a machine with an Intel Pentium 4
3.2 GHz hyper-threaded processor, running Fedora Core 3 Linux. Both
Ice and omniORB were compiled with g++ 3.4.4, with the -O3
optimisation level. The tests run on a single machine, between two
processes. I have only tested C++ so far. I might do some Python
comparisons later.

I used the latest stable releases of Ice and omniORB: 3.0.0 and 4.0.6
respectively.

Both Ice and omniORB are run with no special configuration, so they
use the default options for everything. For omniORB, I tried both the
default TCP transport and the Unix domain socket transport.

So, the results:

The latency test just pings an object. I ran each test three times and
picked the best result:

Ice tcp: time for 100000 pings: 6926.86ms
omniORB tcp: time for 100000 pings: 4566.58ms
omniORB unix: time for 100000 pings: 2373.28ms

omniORB is over 1.5 times faster using TCP, and more than 2.9 times
faster using Unix sockets.

The throughput test looks at the time taken to transfer large
sequences of various types. Each type is tested four ways: sending as
an argument, sending oneway as an argument, receiving as a return
value, and echoing.

The values shown are a throughput in MBit/s, calculated by the test.
Larger numbers are better.

Test Ice omniORB tcp omniORB unix

byte sequence
send 1180.1 2433.7 4788.8
oneway 1321.0 2504.5 4267.8
return 777.5 1184.1 1554.3
echo 950.7 1501.6 2250.3

string sequence
send 78.8 82.9 86.7
oneway 81.6 83.7 88.8
return 60.7 52.2 53.6
echo 66.2 64.4 67.9

struct: string and double
send 178.6 186.6 210.5
oneway 181.4 193.7 211.7
return 129.0 121.9 130.9
echo 145.8 150.0 159.9

struct: two longs and a double
send 611.4 1301.6 2118.0
oneway 567.7 1310.0 2059.1
return 486.7 1052.0 1520.8
echo 545.8 1159.4 1758.5

As you can see, omniORB mostly beats Ice, With fixed length types, it
beats it significantly. Ice wins on a couple of the string sequence
tests and one of the tests with a struct containing a string and a
double.

I think the results with strings are more an artifact of the way the
tests work than anything else. All the tests pre-build the sequences
they are going to transfer. Ice sensibly uses C++ standard strings to
represent the strings; CORBA just uses C-style char* arrays (plus
holder objects for deallocation). Constructing a C++ string is more
expensive than constructing a C string, but once it has been
constructed its length has been pre-calculated. Marshalling a sequence
of existing C++ strings therefore only requires one pass over each
string, while C-style strings require two passes. In a real
application, the strings would probably be constructed during
operation of the program, rather than right at the start, so I'm not
sure this difference would appear in many real situations.

I hope some people find this interesting.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- dun...@grisby.org --
-- http://www.grisby.org --

Siegfried Rohdewald

2005年11月25日下午7时22分显示选项

新闻论坛：comp.object.corba

发件人： "Siegfried Rohdewald" <i...@rayfract.com> - 查找此作者的帖子

日期：25 Nov 2005 03:22:57 -0800

当地时间：2005年11月25日(星期五) 下午7时22分

主题：Re: omniORB and Ice performance compared

Duncan Grisby wrote:

...

> The tests run on a single machine, between two
> processes. I have only tested C++ so far. I might do some Python
> comparisons later.

How does the comparison look if the two processes do not run on the
same machine, but each process on a different machine ?

Siegfried Rohdewald.

Juergen Weber

2005年11月27日上午2时31分显示选项

新闻论坛：comp.object.corba

发件人： "Juergen Weber" <webe...@gmail.com> - 查找此作者的帖子

日期：26 Nov 2005 10:31:33 -0800

当地时间：2005年11月27日(星期日) 上午2时31分

主题：Re: omniORB and Ice performance compared

Thanks Duncan,

that is very interesting.

Maybe somebody would care to repeat the tests using webservices ;-)

The other day I ran a test with a huge real world IDL (lots of nested
structures and sequences), request message size 1K, reply 64K using the
old JDK 1.3.1 implementation (server did nothing but fill the data
structures from dummy data). The round-trip between different machines
took about 70ms, which is about 10^4 slower than your ping numbers, but
still very fast, imho.

Juergen

Rob Ratcliff

2005年11月28日下午1时19分显示选项

新闻论坛：comp.object.corba

发件人： Rob Ratcliff <rrr6...@futuretek.com> - 查找此作者的帖子

日期：Mon, 28 Nov 2005 05:19:13 GMT

当地时间：2005年11月28日(星期一) 下午1时19分

主题：Re: omniORB and Ice performance compared

It also might be interesting to see a comparison between two big endian
machines and a big endian and a little endian machine just to see how
much byte swapping impacts the performance. (Of course CORBA uses
"receiver makes right" and Ice always uses little endian, so I'd expect
to see different trends from each approach.)

- 显示引用的文字 -

Steve Wampler

2005年12月2日上午5时08分显示选项

新闻论坛：comp.object.corba

发件人： Steve Wampler <swamp...@noao.edu> - 查找此作者的帖子

日期：Thu, 01 Dec 2005 14:08:50 -0700

当地时间：2005年12月2日(星期五) 上午5时08分

主题：Re: omniORB and Ice performance compared

Very interesting results. I have a few questions.

On Tue, 22 Nov 2005 12:12:55 +0000, Duncan Grisby wrote:
> Both Ice and omniORB are run with no special configuration, so they
> use the default options for everything. For omniORB, I tried both the
> default TCP transport and the Unix domain socket transport.

This decision concerns me, as the default configurations may
have vastly different philosophies. As an example, the
PostgreSQL database comes configured for operating on small,
slow box - you *have* to reconfigure it to get *any* sort of
decent performance on a typical machine really used for
databases these days. It would be much more useful to see
these comparisons done with both Ice and oO *fully* tuned
for performance.

How does oO 4.0.l6 compare against other ORBs? Specifically,
TAO (which Ice uses in their comparisons) and oO 3.x? If
oO 4.0.6's performance against TAO is consistent with
Ice's performance against TAO, then the above oO vs Ice
numbers have an increased 'validity potential'. If they
don't (for example, if TAO is faster...), then I'm still
left wondering whose version of the performance tests were
done 'right'.

Marc Laukien

2005年12月2日上午5时31分显示选项

新闻论坛：comp.object.corba

发件人： Marc Laukien <m...@zeroc.com> - 查找此作者的帖子

日期：Thu, 01 Dec 2005 16:31:45 -0500

当地时间：2005年12月2日(星期五) 上午5时31分

主题：Re: omniORB and Ice performance compared

I can confirm that omniORB is faster than Ice for the tests that Duncan
performed. omniORB is definitely a well-engineered product, with some
very clever concurrency models. However, the concurrency models are also
not directly comparable to what Ice offers. For example, Ice uses a
leader/follower thread pool both for the server side and the client side
(for AMI callbacks). Whether or not the concurrency model difference is
relevant depends on your application.

I'd also like to point out that we have never claimed that Ice is faster
than omniORB. I know omniORB back from my CORBA days, and it has always
been known to be one of the fastest CORBA implementations.

-- Marc

- 显示引用的文字 -

Douglas C. Schmidt

2005年12月2日上午6时48分显示选项

新闻论坛：comp.object.corba

发件人： schm...@ace.cs.wustl.edu (Douglas C. Schmidt) - 查找此作者的帖子

日期：1 Dec 2005 16:48:57 -0600

当地时间：2005年12月2日(星期五) 上午6时48分

主题：Re: omniORB and Ice performance compared

Hi Folks,

++ On Tue, 22 Nov 2005 12:12:55 +0000, Duncan Grisby wrote:
++ > Both Ice and omniORB are run with no special configuration, so they
++ > use the default options for everything. For omniORB, I tried both the
++ > default TCP transport and the Unix domain socket transport.
++
++ This decision concerns me, as the default configurations may
++ have vastly different philosophies. As an example, the
++ PostgreSQL database comes configured for operating on small,
++ slow box - you *have* to reconfigure it to get *any* sort of
++ decent performance on a typical machine really used for
++ databases these days. It would be much more useful to see
++ these comparisons done with both Ice and oO *fully* tuned
++ for performance.
++
++ How does oO 4.0.l6 compare against other ORBs? Specifically,
++ TAO (which Ice uses in their comparisons) and oO 3.x? If
++ oO 4.0.6's performance against TAO is consistent with
++ Ice's performance against TAO, then the above oO vs Ice
++ numbers have an increased 'validity potential'. If they
++ don't (for example, if TAO is faster...), then I'm still
++ left wondering whose version of the performance tests were
++ done 'right'.

omniORB is widely considered as one of the fastest ORBs around. I
recommend you check out

http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare...
http://nenya.ms.mff.cuni.cz/~bench/

for lots more information, benchmarks, and performance comparisons of
various middleware.

Thanks,

Doug

--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Institute for Software Integrated Systems WEB: www.dre.vanderbilt.edu/~schmidt
Vanderbilt University, Nashville TN, 37203 NET: d.schm...@vanderbilt.edu

AIX上的aio(转贴)

Diviner — Fri, 11 Nov 2005 10:06:00 GMT

http://www.loveunix.net/discuz/viewthread.php?tid=51746&extra=page%3D1

Asynchronous I/O Subsystem

Synchronous I/O occurs while you wait. Applications processing cannot continue until the I/O operation is complete.

In contrast, asynchronous I/O operations run in the background and do not block user applications. This improves performance, because I/O operations and applications processing can run simultaneously.

Using asynchronous I/O will usually improve your I/O throughput, especially when you are storing data in raw logical volumes (as opposed to Journaled file systems). The actual performance, however, depends on how many server processes are running that will handle the I/O requests.

Many applications, such as databases and file servers, take advantage of the ability to overlap processing and I/O. These asynchronous I/O operations use various kinds of devices and files. Additionally, multiple asynchronous I/O operations can run at the same time on one or more devices or files.

Each asynchronous I/O request has a corresponding control block in the application's address space. When an asynchronous I/O request is made, a handle is established in the control block. This handle is used to retrieve the status and the return values of the request.

Applications use the aio_read and aio_write subroutines to perform the I/O. Control returns to the application from the subroutine, as soon as the request has been queued. The application can then continue processing while the disk operation is being performed.

A kernel process (kproc), called a server, is in charge of each request from the time it is taken off the queue until it completes. The number of servers limits the number of disk I/O operations that can be in progress in the system simultaneously.

The default values are minservers=1 and maxservers=10. In systems that seldom run applications that use asynchronous I/O, this is usually adequate. For environments with many disk drives and key applications that use asynchronous I/O, the default is far too low. The result of a deficiency of servers is that disk I/O seems much slower than it should be. Not only do requests spend inordinate lengths of time in the queue, but the low ratio of servers to disk drives means that the seek-optimization algorithms have too few requests to work with for each drive.

Note:
Asynchronous I/O will not work if the control block or buffer is created using mmap (mapping segments).

In AIX 5.2 there are two Asynchronous I/O Subsystems. The original AIX AIO, now called LEGACY AIO, has the same function names as the posix compliant POSIX AIO. The major differences between the two involve different parameter passing. Both subsytems are defined in the /usr/include/sys/aio.h file. The _AIO_AIX_SOURCE macro is used to distinguish between the two versions.

Note:
The _AIO_AIX_SOURCE macro used in the /usr/include/sys/aio.h file must be defined when using this file to compile an aio application with the LEGACY AIO function definitions. The default compile using the aio.h file is for an application with the new POSIX AIO definitions. To use the LEGACY AIO function defintions do the following in the source file:
#define _AIO_AIX_SOURCE
#include <sys/aio.h>
or when compiling on the command line, type the following:
xlc ... -D_AIO_AIX_SOURCE ... classic_aio_program.c

For each aio function there is a legacy and a posix definition. LEGACY AIO has an additional aio_nwait function, which although not a part of posix definitions has been included in POSIX AIO to help those who want to port from LEGACY to POSIX definitions. POSIX AIO has an additional aio_fsync function, which is not included in LEGACY AIO. For a list of these functions, see Asynchronous I/O Subroutines.

How Do I Know if I Need to Use AIO?

Using the vmstat command with an interval and count value, you can determine if the CPU is idle waiting for disk I/O. The wa column details the percentage of time the CPU was idle with pending local disk I/O.

If there is at least one outstanding I/O to a local disk when the wait process is running, the time is classified as waiting for I/O. Unless asynchronous I/O is being used by the process, an I/O request to disk causes the calling process to block (or sleep) until the request has been completed. Once a process's I/O request completes, it is placed on the run queue.

A wa value consistently over 25 percent may indicate that the disk subsystem is not balanced properly, or it may be the result of a disk-intensive workload.

Note:
AIO will not relieve an overly busy disk drive. Using the iostat command with an interval and count value, you can determine if any disks are overly busy. Monitor the %tm_act column for each disk drive on the system. On some systems, a %tm_act of 35.0 or higher for one disk can cause noticeably slower performance. The relief for this case could be to move data from more busy to less busy disks, but simply having AIO will not relieve an overly busy disk problem.

SMP Systems
For SMP systems, the us, sy, id and wa columns are only averages over all processors. But keep in mind that the I/O wait statistic per processor is not really a processor-specific statistic; it is a global statistic. An I/O wait is distinguished from idle time only by the state of a pending I/O. If there is any pending disk I/O, and the processor is not busy, then it is an I/O wait time. Disk I/O is not tracked by processors, so when there is any I/O wait, all processors get charged (assuming they are all equally idle).

How Many AIO Servers Am I Currently Using?
To determine you how many Posix AIO Servers (aios) are currently running, type the following on the command line:
pstat -a | grep posix_aioserver | wc -l

Note:
You must run this command as the root user.
To determine you how many Legacy AIO Servers (aios) are currently running, type the following on the command line:
pstat -a | egrep ' aioserver' | wc -l
Note:
You must run this command as the root user.
If the disk drives that are being accessed asynchronously are using either the Journaled File System (JFS) or the Enhanced Journaled File System (JFS2), all I/O will be routed through the aios kprocs.
If the disk drives that are being accessed asynchronously are using a form of raw logical volume management, then the disk I/O is not routed through the aios kprocs. In that case the number of servers running is not relevant.

However, if you want to confirm that an application that uses raw logic volumes is taking advantage of AIO, you can disable the fast path option via SMIT. When this option is disabled, even raw I/O will be forced through the aios kprocs. At that point, the pstat command listed in preceding discussion will work. You would not want to run the system with this option disabled for any length of time. This is simply a suggestion to confirm that the application is working with AIO and raw logical volumes.
At releases earlier than AIX 4.3, the fast path is enabled by default and cannot be disabled.
How Many AIO Servers Do I Need?
Here are some suggested rules of thumb for determining what value to set maximum number of servers to:
1. The first rule of thumb suggests that you limit the maximum number of servers to a number equal to ten times the number of disks that are to be used concurrently, but not more than 80. The minimum number of servers should be set to half of this maximum number.
2. Another rule of thumb is to set the maximum number of servers to 80 and leave the minimum number of servers set to the default of 1 and reboot. Monitor the number of additional servers started throughout the course of normal workload. After a 24-hour period of normal activity, set the maximum number of servers to the number of currently running aios + 10, and set the minimum number of servers to the number of currently running aios - 10.
In some environments you may see more than 80 aios KPROCs running. If so, consider the third rule of thumb.
3. A third suggestion is to take statistics using vmstat -s before any high I/O activity begins, and again at the end. Check the field iodone. From this you can determine how many physical I/Os are being handled in a given wall clock period. Then increase the maximum number of servers and see if you can get more iodones in the same time period.
Prerequisites
To make use of asynchronous I/O the following fileset must be installed:
bos.rte.aio
To determine if this fileset is installed, use:
lslpp -l bos.rte.aio
You must also make the aio0 or posix_aio0 device available using SMIT.
smit chgaio
smit chgposixaio

STATE to be configured at system restart available
or
smit aio
smit posixaio

Configure aio now
Functions of Asynchronous I/O
Functions provided by the asynchronous I/O facilities are:
• Large File-Enabled Asynchronous I/O
• Nonblocking I/O
• Notification of I/O completion
• Cancellation of I/O requests
Large File-Enabled Asynchronous I/O
The fundamental data structure associated with all asynchronous I/O operations is struct aiocb. Within this structure is the aio_offset field which is used to specify the offset for an I/O operation.
Due to the signed 32-bit definition of aio_offset, the default asynchronous I/O interfaces are limited to an offset of 2G minus 1. To overcome this limitation, a new aio control block with a signed 64-bit offset field and a new set of asynchronous I/O interfaces has been defined. These 64–bit definitions end with "64".
The large offset-enabled asynchronous I/O interfaces are available under the _LARGE_FILES compilation environment and under the _LARGE_FILE_API programming environment. For further information, see Writing Programs That Access Large Files in AIX 5L Version 5.3 General Programming Concepts: Writing and Debugging Programs.
Under the _LARGE_FILES compilation environment, asynchronous I/O applications written to the default interfaces see the following redefinitions:
Item Redefined To Be Header File
struct aiocb struct aiocb64 sys/aio.h
aio_read() aio_read64() sys/aio.h
aio_write() aio_write64() sys/aio.h
aio_cancel() aio_cancel64() sys/aio.h
aio_suspend() aio_suspend64() sys/aio.h
aio_listio() aio_listio64() sys/aio.h
aio_return() aio_return64() sys/aio.h
aio_error() aio_error64() sys/aio.h
For information on using the _LARGE_FILES environment, see Porting Applications to the Large File Environment in AIX 5L Version 5.3 General Programming Concepts: Writing and Debugging Programs
In the _LARGE_FILE_API environment, the 64-bit API interfaces are visible. This environment requires recoding of applications to the new 64-bit API name. For further information on using the _LARGE_FILE_API environment, see Using the 64-Bit File System Subroutines in AIX 5L Version 5.3 General Programming Concepts: Writing and Debugging Programs
Nonblocking I/O
After issuing an I/O request, the user application can proceed without being blocked while the I/O operation is in progress. The I/O operation occurs while the application is running. Specifically, when the application issues an I/O request, the request is queued. The application can then resume running before the I/O operation is initiated.
To manage asynchronous I/O, each asynchronous I/O request has a corresponding control block in the application's address space. This control block contains the control and status information for the request. It can be used again when the I/O operation is completed.
Notification of I/O Completion
After issuing an asynchronous I/O request, the user application can determine when and how the I/O operation is completed. This information is provided in three ways:
• The application can poll the status of the I/O operation.
• The system can asynchronously notify the application when the I/O operation is done.
• The application can block until the I/O operation is complete.
Polling the Status of the I/O Operation
The application can periodically poll the status of the I/O operation. The status of each I/O operation is provided in the application's address space in the control block associated with each request. Portable applications can retrieve the status by using the aio_error subroutine.The aio_suspend subroutine suspends the calling process until one or more asynchronous I/O requests are completed.
Asynchronously Notifying the Application When the I/O Operation Completes
Asynchronously notifying the I/O completion is done by signals. Specifically, an application may request that a SIGIO signal be delivered when the I/O operation is complete. To do this, the application sets a flag in the control block at the time it issues the I/O request. If several requests have been issued, the application can poll the status of the requests to determine which have actually completed.
Blocking the Application until the I/O Operation Is Complete
The third way to determine whether an I/O operation is complete is to let the calling process become blocked and wait until at least one of the I/O requests it is waiting for is complete. This is similar to synchronous style I/O. It is useful for applications that, after performing some processing, need to wait for I/O completion before proceeding.
Cancellation of I/O Requests
I/O requests can be canceled if they are cancelable. Cancellation is not guaranteed and may succeed or not depending upon the state of the individual request. If a request is in the queue and the I/O operations have not yet started, the request is cancellable. Typically, a request is no longer cancelable when the actual I/O operation has begun.
Asynchronous I/O Subroutines
Note:The 64-bit APIs are as follows:
The following subroutines are provided for performing asynchronous I/O:
Subroutine Purpose
aio_cancel or aio_cancel64
Cancels one or more outstanding asynchronous I/O requests.
aio_error or aio_error64
Retrieves the error status of an asynchronous I/O request.
aio_fsync
Synchronizes asynchronous files.
lio_listio or lio_listio64
Initiates a list of asynchronous I/O requests with a single call.
aio_nwait
Suspends the calling process until n asynchronous I/O requests are completed.
aio_read or aio_read64
Reads asynchronously from a file.
aio_return or aio_return64
Retrieves the return status of an asynchronous I/O request.
aio_suspend or aio_suspend64
Suspends the calling process until one or more asynchronous I/O requests is completed.
aio_write or aio_write64
Writes asynchronously to a file.
Order and Priority of Asynchronous I/O Calls

An application may issue several asynchronous I/O requests on the same file or device. However, because the I/O operations are performed asynchronously, the order in which they are handled may not be the order in which the I/O calls were made. The application must enforce ordering of its own I/O requests if ordering is required.

Priority among the I/O requests is not currently implemented. The aio_reqprio field in the control block is currently ignored.

For files that support seek operations, seeking is allowed as part of the asynchronous read or write operations. The whence and offset fields are provided in the control block of the request to set the seek parameters. The seek pointer is updated when the asynchronous read or write call returns.
Subroutines Affected by Asynchronous I/O

The following existing subroutines are affected by asynchronous I/O:
• The close subroutine
• The exit subroutine
• The exec subroutine
• The fork subroutine

If the application closes a file, or calls the _exit or exec subroutines while it has some outstanding I/O requests, the requests are canceled. If they cannot be canceled, the application is blocked until the requests have completed. When a process calls the fork subroutine, its asynchronous I/O is not inherited by the child process.

One fundamental limitation in asynchronous I/O is page hiding. When an unbuffered (raw) asynchronous I/O is issued, the page that contains the user buffer is hidden during the actual I/O operation. This ensures cache consistency. However, the application may access the memory locations that fall within the same page as the user buffer. This may cause the application to block as a result of a page fault. To alleviate this, allocate page aligned buffers and do not touch the buffers until the I/O request using it has completed.

Changing Attributes for Asynchronous I/O
You can change attributes relating to asynchronous I/O using the chdev command or SMIT. Likewise, you can use SMIT to configure and remove (unconfigure) asynchronous I/O. (Alternatively, you can use the mkdev and rmdev commands to configure and remove asynchronous I/O). To start SMIT at the main menu for asynchronous I/O, enter smit aio or smit posixaio.

MINIMUM number of servers
Indicates the minimum number of kernel processes dedicated to asynchronous I/O processing. Because each kernel process uses memory, this number should not be large when the amount of asynchronous I/O expected is small.

MAXIMUM number of servers per cpu
Indicates the maximum number of kernel processes per cpu that are dedicated to asynchronous I/O processing. This number when multiplied by the number of cpus indicates the limit on I/O requests in progress at one time, and represents the limit for possible I/O concurrency.

Maximum number of REQUESTS
Indicates the maximum number of asynchronous I/O requests that can be outstanding at one time. This includes requests that are in progress as well as those that are waiting to be started. The maximum number of asynchronous I/O requests cannot be less than the value of AIO_MAX, as defined in the /usr/include/sys/limits.h file, but it can be greater. It would be appropriate for a system with a high volume of asynchronous I/O to have a maximum number of asynchronous I/O requests larger than AIO_MAX.

Server PRIORITY
Indicates the priority level of kernel processes dedicated to asynchronous I/O. The lower the priority number is, the more favored the process is in scheduling. Concurrency is enhanced by making this number slightly less than the value of PUSER, the priority of a normal user process. It cannot be made lower than the values of PRI_SCHED.
Because the default priority is (40+nice), these daemons will be slightly favored with this value of (39+nice). If you want to favor them more, make changes slowly. A very low priority can interfere with the system process that require low priority.
Attention: Raising the server PRIORITY (decreasing this numeric value) is not recommended because system hangs or crashes could occur if the priority of the AIO servers is favored too much. There is little to be gained by making big priority changes.
PUSER and PRI_SCHED are defined in the /usr/include/sys/pri.h file.

STATE to be configured at system restart
Indicates the state to which asynchronous I/O is to be configured during system initialization. The possible values are:
• defined, which indicates that the asynchronous I/O will be left in the defined state and not available for use
• available, which indicates that asynchronous I/O will be configured and available for use

STATE of FastPath
The AIO Fastpath is used only on character devices (raw logical volumes) and sends I/O requests directly to the underlying device. The file system path used on block devices uses the aio kprocs to send requests through file system routines provided to kernel extensions. Disabling this option forces all I/O activity through the aios kprocs, including I/O activity that involves raw logical volumes. In AIX 4.3 and earlier, the fast path is enabled by default and cannot be disabled.

64-bit Enhancements
Asynchronous I/O (AIO) has been enhanced to support 64-bit enabled applications. On 64-bit platforms, both 32-bit and 64-bit AIO can occur simultaneously.
The struct aiocb, the fundamental data structure associated with all asynchronous I/O operation, has changed. The element of this struct, aio_return, is now defined as ssize_t. Previously, it was defined as an int. AIO supports large files by default. An application compiled in 64-bit mode can do AIO to a large file without any additional #define or special opening of those files.

看来很久之前的以讹传讹是在是影响太厉害了。
1、aio server不是进程，是kernel threading，所以效率才高，要不不如用用户态的thread或者processor实现AIO算了。
2 and 3 显然find使用的syscall是read而不是aio_read，所以只能用阻塞IO，就算你配置了AIO ENABLE也不可能出现你说的3的情况。
4、最大的以讹传讹，AIO可以用于RAW DEVICE，而且效果更好。因为大多数的UNIX的AIO实现是这样的，如果对RAW DEVICE用aio_read aio_write是，是用kernel threading，效率最高；但是对于FS，只能用lwp 或者thread模拟，效率低很多。所以在使用INFORMIX DB2等等DBMS的时候，要充分发挥aio的效果，应该用raw device做数据容器。
5、再次强调，aio server是kernel threading，和用户自己创建的thread或者process都不同。当然AIO SERVER没有必要配置的太多，要根据应用和使用的磁盘控制器数量等决定。

网络编程常用设计模式

Diviner — Sat, 29 Oct 2005 15:46:00 GMT

Abstract Factory [GoF95] provides an interface for creating families of related or dependent objects without specifying their concrete classes.

Abstract Manager [Lieb01] focuses on the management of business objects in enterprise systems.

Activator [Stal00] helps to implement efficient on-demand activation and deactivation of services that are accessed by multiple clients.

Active Object [POSA2] decouples method execution from method invocation.

Adapter [GoF95] converts the interface of a class into an interface expected by clients. Adapter allows classes to work together that could not do so otherwise because of incompatible interfaces.

Asynchronous Completion Token [POSA2] allows an application efficiently to demultiplex and process the responses of asynchronous operations it invokes on services.

Cache Management [Gran98] focuses on caching objects in Java and on how to combine a cache with the Manager [Somm98] pattern.

Cache Proxy [POSA1] implements caching inside a proxy that represents the data source from which one or multiple clients want to retrieve data.

Comparand [CoHa01] provides a means of interpreting differing objects as being the same in specific contexts. It does this by introducing an instance variable, the comparand, in each class of interest, and using it for comparison. Establishing the ‘sameness’ of differing objects is necessary when more than one reference refers conceptually to the same object.

Component Configurator [POSA2] allows an application to link and unlink its component implementations at run-time without having to modify, recompile, or statically relink the application.

Command Processor [POSA1] separates the request for a service from its execution. A command processor component manages requests as separate objects, schedules their execution, and provides additional services such as storing request objects for later undo.

Data Transfer Object [Fowl02] carries data, for example other objects or invocation parameters, between remote clients and servers. The encapsulation provided by this pattern reduces the number of remote operations required to transfer such data.

Deployer [Stal00] describes how to configure, deploy, and install software artifacts.

Disposal Method [Henn03] encapsulates the concrete details of object disposal by providing an explicit method for cleaning up objects, instead of abandoning the objects to be garbage collected or terminating them by deletion.

Double-Checked Locking Optimization [POSA2] reduces contention and synchronization overheads when critical sections of code must acquire locks in a thread-safe manner just once during program execution.

Factory Method [GoF95] defines an interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

Fixed Allocation [NoWe00] allows memory consumption to be predicted by allocating the necessary memory at program initialization.

Flyweight [GoF95] uses sharing to support large numbers of fine-grained objects efficiently.

Half-Object Plus Protocol [Mesz95] divides the responsibilities of an object into halves and assigns them to two interdependent half-objects when an object is used by two distributed clients. For efficiency reasons, each half-object implements the responsibility that is most used locally. This pattern lets the half-objects coordinate themselves via some protocol.

Interceptor [POSA2] allows services to be added to a framework transparently and triggered automatically when specific events occur.

Lazy Load [Fowl02] defers the loading of data from databases until it is first accessed.

Lazy Optimization [Auer96] optimizes the performance of a piece of software only after the design has been correctly determined.

Lazy Propagator [FeTi97] describes how, in a network of dependent objects, objects can determine when they are affected by the state changes of other objects, and therefore need to update their state.

Lazy State [MoOh97] defers the initialization of the state of an object [GoF95] until the state is accessed.

Manager [Somm98] places functionality that applies to all objects of a class into a separate management object. This separation allows the independent variation of management functionality and its reuse for different object classes.

Master-Slave [POSA1] supports fault tolerance, parallel computation and computational accuracy. A master component distributes work to identical slave components and computes a final result from the results returned by the slaves.

Mediator [GoF95] defines an object that encapsulates the way in which a set of objects interact. Mediator promotes loose coupling by keeping objects from referring to each other explicitly, and allows their interaction to be varied independently.

Memento [GoF95] encapsulates the state of an object in a separate, persistable object.

Model-View-Controller [POSA1] divides an interactive application into three components. The model contains the core functionality and data, the view displays information to the user, and the controller handles user input. The view and controller together comprise the user interface. A change-propagation mechanism ensures consistency between the user interface and the model.

Object Lifetime Manager [LGS01] is specialized for the management of singleton objects in operating systems that do not support static destructors properly, such as real-time operating systems.

Object Pool [Gran98] manages the reuse of objects of a type that is expensive to create, or of which only a limited number can be created.

Page Cache [TMQH+03] improves response times when dynamically-generated Web pages are accessed. A page cache is associated with a Web server that uses it to store accessed pages indexed by their URLs. When the same URL is requested, the Web server queries the cache and returns the cached page instead of dynamically generating its contents again.

Passivation [VSW02] persists and activates memory representations of component instances to and from persistent storage.

Pooled Allocation [NoWe00] pre-allocates a pool of memory blocks, recycling them when returned.

Proxy [GoF95] provides a surrogate or placeholder for another object, to control access to it.

Proactive Resource Allocation [Cros02] anticipates system changes and plans necessary resource allocations ahead of time, with the goal of maintaining system performance even under changed conditions.

Reactor [POSA2] allows event-driven applications to demultiplex and dispatch service requests that are delivered to an application from one or more clients.

Reflection [POSA1] provides a mechanism for changing the structure and behavior of software systems dynamically. A meta level provides information about selected system properties and makes the software self-aware.

Resource Exchanger [SaCa96] reduces a server's load when allocating and using resources by sharing common buffers that are passed between clients and servers.

Singleton [GoF95] ensures a class has only one instance, and provides a global point of access to it.

Sponsor-Selector [Wall97] separates three fundamentally different responsibilities: recommending a resource, selecting among resources, and using a resource.

State [GoF95] allows an object to alter its behavior when its internal state changes.

Strategy [GoF95] encapsulates logic, such as algorithms, into interchangeable classes that are independent of client requests.

Thread-local Memory Pool [Somm02] allows a memory allocator to be created for each thread. This helps to reduce synchronization overheads, since dynamic memory allocations are performed from a thread-local pool of pre-allocated memory.

Thread Pooling [PeSo97] describes how to bound the number of threads used and how to reuse unused threads.

Variable Allocation [NoWe00] optimizes memory consumption by performing memory allocations on demand.

Virtual Proxy [GoF95] loads or constructs the object that the proxy represents on demand.

Wrapper Facade [POSA2] encapsulates the functions and data provided by existing non-object-oriented APIs within more concise, robust, portable, maintainable, and cohesive object-oriented class interfaces.