Three Good Tips

1.  Let a perl process sleep less than 1 second

 

From the Perldoc page on sleep :

For delays of finer granularity than one second, the Time::HiRes module (from CPAN, and starting from Perl 5.8 part of the standard distribution) provides usleep().

Actually, it provides usleep() (which sleeps in microseconds) and nanosleep() (which sleeps in nanoseconds). You may want usleep() , which should let you deal with easier numbers. 1 millisecond sleep (using each):

use
 strict
;



use
 warnings
;





use
 
Time
::
HiRes
 qw
(
usleep nanosleep
);





# 1 millisecond == 1000 microseconds


usleep
(
1000
);



# 1 microsecond == 1000 nanoseconds


nanosleep
(
1000000
);

If you don't want to (or can't) load a module to do this, you may also be able to use the built-in select() function:

# Sleep for 250 milliseconds



select
(
undef
,
 
undef
,
 
undef
,
 
0.25
);



2. Support more file descriptors






echo 32768 > /proc/sys/fs/file-max



increases the system limit on open files, and

ulimit -n 32768

increases the current process' limit.   



3. I/O Strategies

Designers of networking software have many options. Here are a few:

• Whether and how to issue multiple I/O calls from a single thread
  • Don't; use blocking/synchronous calls throughout, and possibly use multiple threads or processes to achieve concurrency
  • Use nonblocking calls (e.g. write() on a socket set to O_NONBLOCK) to start I/O, and readiness notification (e.g. poll() or /dev/poll) to know when it's OK to start the next I/O on that channel. Generally only usable with network I/O, not disk I/O.
  • Use asynchronous calls (e.g. aio_write()) to start I/O, and completion notification (e.g. signals or completion ports) to know when the I/O finishes. Good for both network and disk I/O.
• How to control the code servicing each client
  • one process for each client (classic Unix approach, used since 1980 or so)
  • one OS-level thread handles many clients; each client is controlled by:
    • a user-level thread (e.g. GNU state threads, classic Java with green threads)
    • a state machine (a bit esoteric, but popular in some circles; my favorite)
    • a continuation (a bit esoteric, but popular in some circles)
  • one OS-level thread for each client (e.g. classic Java with native threads)
  • one OS-level thread for each active client (e.g. Tomcat with apache front end; NT completion ports; thread pools)
• Whether to use standard O/S services, or put some code into the kernel (e.g. in a custom driver, kernel module, or VxD)

Reference: http://www.kegel.com/c10k.html
; http://pl.atyp.us/content/tech/servers.html