Finding windows FastCGI help is proving very difficult.
Any help would be greatly apprciated.
The concept of FastCGi is that the process survives a request allowing you to maintain state between calls. This means you do not have the overhead of opening databases etc between calls.
Apart from that, FastCGI is fully multiplexed:
http://cryp.to/publications/fastcgi/#MULTIPLEXING
The problem lies in the C API
The source for libfcgi.dll is available here:
http://www.fastcgi.com/drupal/node/5
This is not supported by MS as anyone connected with FCGI or IIS points out in a hurry
A new windows FastCGI library was needed to implement the FastCGI SIGTERM handler
www.coastrd.com
Related
I understand the purpose of FastCGI in terms of performance over other gateway interfaces. But if libraries that implement FastCGI already have to go through the painstaking measures of implementing a secure and efficient TCP service, why not just write applications as a web server? Is it less efficient for a front-end web server to implement a reverse proxy than it is for FCGI? Or is the specification for FCGI that much simpler than that of HTTP?
I had a web server program that I replaced with an FCGI program. Part of the reason I did it was because of the requirements of the program. It needed to run under the existing web server since doing so would require no additional configuration.
Another requirement was that it would be able to track some state values that can change frequently. The existing program wasn't very efficient, tracking these state values externally and doing a fresh load of them for every request. One advantage of an FCGI program is that it is persistent, so it could poll those state values and they would be available and ready for every request.
I didn't have to implement any of the FCGI spec, I just used an existing FCGI library and it handled all the communication with the web server for me. Compared to other applications I've written that have an embedded web server, implementing one with the FCGI library was relatively simple.
Another advantage of FCGI is that an FCGI application doesn't need to actually reside on a disk accessible to the web server. You can configure the server to establish a TCP connection to an instance of your FCGI application on another server. If you are in a situation where you can't access the web server directly, this can be very useful. Accomplishing the same thing with other methods can be cumbersome, but an FCGI application doesn't even need to be modified. Just configure the server, launch your app under the FCGI host, and you are good to go.
Yet another advantage of FCGI is that you can configure the web server to distribute requests between a preset number of instances of your application. If your web application works best by handling every request synchronously, FCGI is ideal because you can funnel every request into a single instance, and that instance can handle each request in a single loop. If you want at most 2, 3, or n instances all you need to do is change the value on the server and you can accomplish that.
So, FCGI isn't the best for every situation. It's the times you are faced with unusual requirements that FCGI is most attractive.
We have a C/S application all written in Delphi (Client and Server-or middleware if you want)
For the client part we use Indy.
For the server we use DXSock.
Since DXSock is dead for a while we are investigating alternatives for the sever part.
I want to hear some comments about the best Server Socket alternative component for Delphi.
The current system usually have tens of permanent connections working each one on its own thread but could be hundreads in the future (this should be improved to a thread pool if possible)
If you want to have the best possible performance, you'd have to use sockets in non blocking mode, or using completion ports. IPWorks is implemented like that, as well as iocp. As far as I can tell, Indy or Synapse don't implement them (at least officially).
We used completion ports and a thread pool in our open source SynCrtSock unit, used in our Synopse SQLite3 framework.
Here are some benchmarks of this solution, working from Delphi 6 up to Delphi XE. I don't tell this is the "best component", but it's a working and speedy one (every request is about 4 KB of JSON data):
Http client keep alive (i.e. one HTTP/1.1 client connection kept alive during requests):
first in 7.87ms, done in 153.37ms i.e. 6520/s, average 153us
Http client multi connect (i.e. one new HTTP/1.0 client connection created for each request - this one uses completion ports and a thread pool):
first in 151us, done in 305.98ms i.e. 3268/s, average 305us
For speed comparison, here are other communication protocols available in our framework:
Named pipe access:
first in 78.67ms, done in 187.15ms i.e. 5343/s, average 187us
Local window messages:
first in 148us, done in 112.90ms i.e. 8857/s, average 112us
Direct in process access:
first in 44us, done in 41.69ms i.e. 23981/s, average 41us
We use HTTP/1.1 protocol over TCP/IP, because there is very little overhead over plain TCP/IP, and this is a well handled protocol for firewalls and such, and allows our framework to be used by an AJAX application, whereas its main purpose is to serve Delphi clients.
IMHO there is no "best Server Socket alternative component for Delphi", it depends what is the purpose of your server application. The main bottleneck will be in the Windows kernel itself. Perhaps direct access to the HTTP Kernel-Mode Driver (Http.sys) of Windows could help.
Consider using a dedicated optimized Server instead of a Delphi server, like lighttpd or Cherokee using FastCGI to handle the requests via a Free Pascal (or CrossKylix) application, under Linux. I guess this will be the best performance possible.
I use Indy components for commercial server-side work and the component set is pretty solid (9 or 10). My servers have millions of connections per day with no issues.
I used DXSock many moons ago. He was always optimizing, but never seemed to finish it. He does seem to have another version out.
If you want commercial support, then I'd recommend IPWorks from nSoftware.
Actually DXSock is not dead, v6.1 was just released. The web hosting company we used to use in Tennessee lost the domain - so only customers who have kept their subscription renewed annually have received DXSock 5.0, 6.0 and 6.1.
Indy CANNOT support more than 2,000 concurrent connections on 32bit Windows - as Chad and crew use TThread, which implements the defacto 1MB per thread/socket connection - 2000x1MB = >2.5GB of RAM which 32bit OSes do not support. DXSock implements a 0b per connection model (unless you define otherwise) and can handle over 50,000 concurrent on Windows, Linux, Mac, Pi, etc.
Ozz Nixon - ozznixon#bpdx.com if you want more details on 6.1
Author of DXSock
Co-Author of Winshoes which became INDY.
I have a server and some clients (about 50) in an intranet. The clients send short (about 40 character) string data to the server and the server answers with a similar string. There are up to (but not permanently) 2-3 requests per second for each client. The server has to serialize the requests to get the response strings.
The system should have as less as possible impact on the network as possible (i.e. the server may run something like a webserver already). It should be as easy to install and administer as possible.
What are the possibilities to achieve this using Delphi (Client: D7, Server up to D2010)?
I use the Synapse library for such a simple server. Its lightning fast, very light, and threads easily. The demo Echo in the main synapse install is a fantastic start for what your trying to do. If you are going to be performing database access inside each request/response thread then I strongly also suggest looking at the connection pool example by Cary Jensen to keep your database connections in check.
TCP, definitely. But I'd like to give a vote for ICS. Never liked Indy ...
What about Indy's TIdTCPServer and TIdTCPClient? They provide command handlers, which makes implementing text-based protocols very straight-forward.
There are a lot of options.
Ultimately, I agree with Smasher and like using sockets. They're quick, easy and portable. If you're dealing with a fairly simple protocol and don't need a full n-tier solution, creating a TCP or HTTP server application is dead simple, very light weight, and easy to make compatible with any client. You can even add SSL support to these stand alone applications without having to configure a web server or interfering with it, if it's already running on the same box.
I use RemObjects SDK for this sort of purpose. It takes care of all the difficult stuff, and I just ask it to connect and make function calls to pass the data.
I want to use Erlang for some background processing and stuff for a web app. I read about its concurrency handling and stuff and I have started learning it. What I want to do specifically is a persistent connection with the clients using COMET - with the Erlang process co-ordinating the HTTP client connections.
Do I need a Erlang based web server for this?
For the actual implementation, how does the "spawn"-ing work in Erlang. I downloaded the erlang ebook and read about spawning. In the case for my web based script, when two clients connect to the same Erlang script by making an HTTP request - can I automatically "spawn" new threads for each of them, and do message passing?
No, you didn't but it is simplest way. You can combine Erlang with libevent to achieve more http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3/
Yes, spawn new client is cheap, if you want cheaper see above.
I would highly recommend using an erlang based webserver to handle the comet connections. The lightweight processes in erlang are half the benefit of using it for this type of thing.
Most of the erlang webserver frameworks will handle the spawning for you. No need to reimplement it yourself. See nitrogen and mochiweb for examples of really dead simple comet implementations.
Did you see the page http://beebole.com/erlang ?
It contains:
how to setup an Erlang environment(with Mochiweb) on Ubuntu
how to install the Nginx web server
a video tutorial to build a small web app using Erlang
You should investigate 'YAWS' (high performance HTTP server) modules: easy to write, full flexibility. YAWS is easily installed: apt-get install yaws (on Ubuntu at least).
Another option would be to use Nitrogen - this allows an easy integration of Erlang code in web pages, including a fully-fledged webserver, and comet.
Is it possible to emulate incoming messages using Indy (if it's of any importance: I'm using Indy 10 and Delphi 2009)? I want to be able to create these messages locally and I want Indy to believe that they come from specific clients in the network. All the internal Indy handling (choice of the thread in which the message is received and stuff like that) should be exactly the same as if the message would have arrived over the network.
Any ideas on that? Thanks in advance for any tips.
What you want to do has nothing to do with Indy, as you would need to do this on a much lower level. The easiest way to make Indy believe that messages come from a specific client is to inject properly prepared packets into the network stack. Read up on TCP Packet Injection on Google or Wikipedia. EtterCap is one such tool that allows to inject packets into established connections. However, this is definitely going into gray areas, as some of the tools are illegal in some countries.
Anyway, all of this is IMHO much too complicated. I don't know what exactly you want to do, but a specially prepared client or server is a much better tool to emulate certain behaviour while developing server or client applications. You can run them locally, or if you need to have different IP addresses or subnets you can do a lot with virtual machines.
Indy doesn't have any built-in mechanisms for this but thinking off the top of my head I would recommend building a small test application (or a suite) that runs locally on your development machine and connects to your Indy server application to replay messages.
It should be irrelevant to your Indy server applications if a TCP connection is made either locally or from a remote host as the mechanisms by which a server thread is created and a command processed is identical to both scenarios.
My last gig involved using Indy and all our testing was done with a similar Resender type application that would load local message files and send these to the Indy server app.
HTH and good luck!
One thing you can do would be to create virtual machines to run your test clients, that way they will not be seen as "local machine", and its fairly simple to create a complex network with VMS -- provided you have enough memory and disk space. The other advantage of testing with VM's is you can eliminate the development environment completely when its time to focus on deployment. Amazing how much time that saves alone.
VirtualPC is a free download from Microsoft and works fairly well. VMWare has another option, but costs a little more to get started. For development purposes, I prefer the desktop versions but the server versions also work well. You will still need to have a license to install the virtual OS. MSDN membership is probably the cheapest way to go, and allows you to build test environments for other flavors of the OS.
Indy has abstract stack mechanism for crossplatform support (IDStack.pas) I think u can hack the stack for windows (IdStackWindows.pas). It is a class. U can even consider to derivate it and override some functions to do the hack.