About migrating application to POSIX THREADS

[Jon Pinkley]

Here's an interesting document that you should scan, at least the following sections: General Design, Server Behaviour, Multi-Threaded, AST Behaviour, Server "Tasks", Memory Management, and Output Buffering sections.

http://wasd.vsm.com.au/ht_root/src/httpd/readmore.txt

It's the Nuts and Bolts document describing the WASD HTTP Server. It is a highly concurrent, multi-threaded (with AST's, not a threading library) HTTP server.

The WASD VMS Hypertext Services - Technical Overview http://wasd.vsm.com.au/ht_root/doc/htd/ has a chapter on performance (21). This is the first paragraph

"The server has a single-process, multi-threaded, asynchronous I/O design. On a single-processor system this is the most efficient approach. On a multi-processor system it is limited by the single process context (with scripts executing within their own context). For I/O constrained processing (the most common in general Web environments) the AST-driven approach is quite efficient."

I think it would be worth your time to look at that before you decide to rewrite using pthreads.

Good Luck,

Jon

[Ian Miller.]

multiple posix threads in a process are co-ordinated by a by a mutex. IIRC there can be only one of them calling a system service at any time. So your bottleneck may be contention for this muxtex. The PTHREAD or MTX SDA extensions may help to determine this (although they are not documented but have some built in help)

[Robert Gezelter]

Jon,

Indeed. When I speak and teach about implementing concurrency, I always speak about a "pyramid of complexity". Ascending each step of the pyramid requires a positive statement. For example:

- Going from simple sequential code to event driven code requires that the sequence of events be indeterminate (e.g., timeouts and network connections, or multiple network connections). A simple payroll computation program would never present that condition.

- Going from non-preemptable threading (e.g., AST, the equivalent in POSIX threads) requires that the processing of each event exceed the computational capacity of a single CPU OR introduces unacceptably long latencies.

In thirty years of working with event driven code and threads, I can only count a relative handful of cases that met the second criteria needed to go to pre-emptable threads. In most cases where pre-emptable threads were perceived to be "the solution", the true underlying problem was some form of synchronous processing that became [unnecessarily] embedded in the event processing.

WASD is a good example of how high performance is quite achievable.

- Bob Gezelter, http://www.rlgsc.com

[Bob CI]

Thanks to everybody for so complete answers. I need some time to analize these informations. In this moment, i´m developing new codes with a multiprocess schema ( 2 servers with the same capabilities, every server del with the half of all clients ), but, at the moment, doesn´t achieve better results that before with a unique process. Because i need to sinchronizing the concurrent access at one of the application file, i use a lock for this operation. Asinchronous part works better, and is be able to deal with more messages ( every process accumulate more messages in global terms that with a unique process), but i´m afraid i have the bottleneck with the application files. And the cost of sinchronizing is high.


Thanks for everybody and i´ll tell you my advances.....

[Hein van den Heuvel]

>> 2 servers with the same capabilities, every server del with the half of all clients ), but, at the moment, doesnà ´t achieve better results that before with a unique process

Well Duh! No kidding huh? !?

You would have the same (file) locking as with 1 process. I fact it may well be worse as RMS now may have to 'ping' the most recent block from one process to the next and back aided byt the XFC (after writing to the disk)

>> afraid i have the bottleneck with the application files.

Well Duh!

That would be true for 95% of all your applications. If if was not true the application you work on, then you would have known this and would have been able to 'proof' it with argumentation.

>> And the cost of sinchronizing is high.

Duh!

I see stuff like applications taking out a lock, reading a record which holds a next value, update, write new record using that next new value, release the lock. All they needed to do was to just keep the next-new-key value in the lock value block, update teh underlyng storage ever 10 minutes or 100 updates, and release the lock for the next user.

Good luck!
Hein van den Heuvel (at gmail dot com)
HvdH Performance Consulting

[Robert Gezelter]

Roberto,

Designing for performance can be subtle. Your most recent posting included the comment:

"... Because i need to sinchronizing the concurrent access at one of the application file, i use a lock for this operation. ..."

This may be a mis-communication, but if a single lock is being used to control access to the file as a whole, that would be an unneeded bottleneck. RMS shared writing does things far more efficiently than that, as can a directly implemented non-RMS scheme.

If this is the problem, a correction would be far more less work than restructuring to a different approach (and the different approach may very well not yield the benefits desired).

- Bob Gezelter, http://www.rlgsc.com

[Hoff]

Do you know where the code is spending its time?

Build and invoke with the DECset tool Performance and Coverage Analyzer (PCA) within this application as currently designed, and find out where the code is (really) spending its time. Be prepared for surprises.

On newer OpenVMS versions, you can use some of the built-in PC profiling tools (SDA Extensions), but DECset PCA does a better and more complete job.