Menu
News
Features
Requirements
Manual
Downloads
FAQ
Benchmarks
History
Projects
existing MUGIs
dpfTVS and CGI
Contact/Impressum
This project has been discontinued January 2005
Yes, another web-server for Linux. There are a lot others out there. Some are free, some are expensive. They all have one thing in commen, they are already there. So why would anybody write just another server when we have free ones like Apache
or thttpd? In case you really want to know, follow the history link on the left side...
The core technology I use is "dynamic pre-forking" or "dynamic pre-threading". Now what does that mean exactly. Normally you either fork dynamically, you pre-fork or you use threads. Forking is slow compared to threading, but CGI scripts have to be forked and that is a lot slower when a multi-threaded program has a lot threads running. Pre-forking tries to take care of the most negativ effect of forking, the creation time of a new process. But that usually comes either with a lot wasted resources or with not enough pre-forked worker processes. dpfTVS forks new processes if there is need of more, but keeps the ones already there for a certain time to re-use them if nescessary. dpfTVS also does the same for threads, it's not as effective on NPTL enabled kernels as NPTL already does something alike. Forked processes have a lot advantages, so for example they are more stable as an error won't effect the whole server, CGI scripts start a lot faster as there is no thread overhead to take care of and so on. The dynamic pre-fork takes away most of the negativ speed effects simple forking would have and it doesn't have the resource wasting one of the simple pre-fork. dpfTVS can be setup to either run with processes or threads and yes, I am proud of it.
Who is it for? Well, if you use mainly PHP, Perl or Java-servelets running with Apache and the appropriate module on a single server, then definitely not for you. dpfTVS might be of intrest if mainly static content is served as it is fast when the clients are http/1.1 capable. It is also fast when you use CGI scripts that don't benefit from module technology. But basically it is for programmers/developers who use for example C/C++ to create server like applications to connect them via MUGI. Later on, when more MUGI applications are finished it will also be an alternative for those that have only limited resources available. After all, for example a forum written in PHP using a SQL database along with it might be the most convenient solution, but definitely not the most economic one.
The dynamic linked server binary is free to download and use. It is neither opensource (GPL) nor public domain. You are not allowed to add it to a distribution, a product or offer it for download in any form without my consent. The MUGI protocol on the other hand is public domain, so you can implement it in your own www-server if you like.
Please use the old systems forum for questions and comments.
The final goal is not to provide just another server. It is to provide a set of applications and tools using MUGI and custom databases as a less resource demanding alternative to the already established solutions.
Yes, another web-server for Linux. There are a lot others out there. Some are free, some are expensive. They all have one thing in commen, they are already there. So why would anybody write just another server when we have free ones like Apache
or thttpd? In case you really want to know, follow the history link on the left side...The core technology I use is "dynamic pre-forking" or "dynamic pre-threading". Now what does that mean exactly. Normally you either fork dynamically, you pre-fork or you use threads. Forking is slow compared to threading, but CGI scripts have to be forked and that is a lot slower when a multi-threaded program has a lot threads running. Pre-forking tries to take care of the most negativ effect of forking, the creation time of a new process. But that usually comes either with a lot wasted resources or with not enough pre-forked worker processes. dpfTVS forks new processes if there is need of more, but keeps the ones already there for a certain time to re-use them if nescessary. dpfTVS also does the same for threads, it's not as effective on NPTL enabled kernels as NPTL already does something alike. Forked processes have a lot advantages, so for example they are more stable as an error won't effect the whole server, CGI scripts start a lot faster as there is no thread overhead to take care of and so on. The dynamic pre-fork takes away most of the negativ speed effects simple forking would have and it doesn't have the resource wasting one of the simple pre-fork. dpfTVS can be setup to either run with processes or threads and yes, I am proud of it.
Who is it for? Well, if you use mainly PHP, Perl or Java-servelets running with Apache and the appropriate module on a single server, then definitely not for you. dpfTVS might be of intrest if mainly static content is served as it is fast when the clients are http/1.1 capable. It is also fast when you use CGI scripts that don't benefit from module technology. But basically it is for programmers/developers who use for example C/C++ to create server like applications to connect them via MUGI. Later on, when more MUGI applications are finished it will also be an alternative for those that have only limited resources available. After all, for example a forum written in PHP using a SQL database along with it might be the most convenient solution, but definitely not the most economic one.
The dynamic linked server binary is free to download and use. It is neither opensource (GPL) nor public domain. You are not allowed to add it to a distribution, a product or offer it for download in any form without my consent. The MUGI protocol on the other hand is public domain, so you can implement it in your own www-server if you like.
Please use the old systems forum for questions and comments.
The final goal is not to provide just another server. It is to provide a set of applications and tools using MUGI and custom databases as a less resource demanding alternative to the already established solutions.