On 10/31/05, Nick Kew <nick@xxxxxxxxxxxx> wrote: > > No, because I'd like it to be (more) independent of the web server. > > Apache could be either multi-threaded or multi-processed, but my app > > would be single-threaded (epoll). > > That's a lot of constraints to be putting on yourself if they're > not there already - imposed by existing software! Why? I expect no CPU intensive algorithms, so a single thread and a single process look like the best approach. If such an algorithm would be needed I'd probably use a few worker threads to execute them, but I'd not use one thread per connection/request. > > Also, if my app crashes, the web server shouldn't crash. > > So, the opposite of the PHP approach :^) Yes. Actually, I'm wondering why such an approach isn't frequently used for PHP too. > > This would be connecting to an 'application' server (if that's the right > > word). > > Indeed, but that says nothing about the protocol used. But is DBD suitable for talking to an app server? It could be if it's generalised to RPC. > > I'd like to cache (much) more than connections. > > Apache has mod_cache for cacheing contents. But that's not usable due to the requirement of independence from Apache.
|