view release on metacpan or  search on metacpan

README  view on Meta::CPAN

    POE also performs much better in this case, but is is still far behind
    the others.

   Summary
    *   C-based event loops perform very well with small number of watchers,
        as the management overhead dominates.

  THE IO::Lambda BENCHMARK
    Recently I was told about the benchmark in the IO::Lambda manpage, which
    could be misinterpreted to make AnyEvent look bad. In fact, the
    benchmark simply compares IO::Lambda with POE, and IO::Lambda looks
    better (which shouldn't come as a surprise to anybody). As such, the
    benchmark is fine, and mostly shows that the AnyEvent backend from
    IO::Lambda isn't very optimal. But how would AnyEvent compare when used
    without the extra baggage? To explore this, I wrote the equivalent
    benchmark for AnyEvent.

    The benchmark itself creates an echo-server, and then, for 500 times,
    connects to the echo server, sends a line, waits for the reply, and then
    creates the next connection. This is a rather bad benchmark, as it
    doesn't test the efficiency of the framework or much non-blocking I/O,

lib/AnyEvent.pm  view on Meta::CPAN

=item * C-based event loops perform very well with small number of
watchers, as the management overhead dominates.

=back

=head2 THE IO::Lambda BENCHMARK

Recently I was told about the benchmark in the IO::Lambda manpage, which
could be misinterpreted to make AnyEvent look bad. In fact, the benchmark
simply compares IO::Lambda with POE, and IO::Lambda looks better (which
shouldn't come as a surprise to anybody). As such, the benchmark is
fine, and mostly shows that the AnyEvent backend from IO::Lambda isn't
very optimal. But how would AnyEvent compare when used without the extra
baggage? To explore this, I wrote the equivalent benchmark for AnyEvent.

The benchmark itself creates an echo-server, and then, for 500 times,
connects to the echo server, sends a line, waits for the reply, and then
creates the next connection. This is a rather bad benchmark, as it doesn't
test the efficiency of the framework or much non-blocking I/O, but it is a
benchmark nevertheless.

lib/AnyEvent/TLS.pm  view on Meta::CPAN

If the certificate file or string contain both the certificate and
private key, then there is no need to specify a separate C<key_file> or
C<key>.

Additional signing certifiates to send to the peer (in SSLv3 and newer)
can be specified by appending them to the certificate proper: the order
must be from issuer certificate over any intermediate CA certificates to
the root CA.

So the recommended ordering for a combined key/cert/chain file, specified
via C<cert_file> or C<cert> looks like this:

  certificate private key
  client/server certificate
  ca 1, signing client/server certficate
  ca 2, signing ca 1
  ...

=item cert => $string

The local certificate in PEM format (might be a combined