Indy creates one thread per client connection. Inside that thread you then do your database work using a DB connection pool.
Ie. 25 Indy Client Threads share 5 DB connections using critical section style lock and aquire techniques. There are many examples floating around of Writing a connection pooling object for databases. As far as indy goes. The secret is to not keep all your clients connected all the time. It is better to do it in a similar fashion to HTTP where each client connects for the period of doing a particular batched request and closes down again. This essentially is how you get connection pooling. You may have a 1000 clients using a GUI but if only 100 are requesting data at a time you minimise your resource use. If you keep session objects in your server for a life-time managed object based on user and IP address then each reconnection can easily be verified. > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf Of Eric Tishler > Sent: Thursday, 22 July 2004 12:21 a.m. > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > Stephen, > > Your insight and experience are valuable and greatly appreciated. > > We are using Firebird 1.0.3 and IB Objects which does not have connection > pooling. But, IB Objects comes with a tutorial and example code on how to > set up thread pooling, each with its own unique connection to the database > (connection pooling of sorts). So I am left wondering if the same would > apply for Indy. That is use the thread pooling to handle each socket > connection request and subsequent messaging for that particular session. I > may be wrong, but it seems that a properly threaded application would take > load off the socket component on onto the Delphi application itself. > > Perhaps I am over simplifying in this case? > > Either way, the FPiette socket components have other inherent problems. So > I am inclined to go with Indy. > > Thank you for your input. > > Eric > > Eric Tishler > Software Architect > Resolute Partners, LLC > Phone: 203.271.1122 > Fax: 203.271.1460 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:delphi- > [EMAIL PROTECTED] On Behalf Of Stephen Bertram > Sent: Tuesday, July 20, 2004 6:19 PM > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > A word of warning - Indy is not totally scalable. If you read the Indy > forums there are specific warnings that it is not designed for ultra > heavy use. > > We are running into problems when we increase the connections from 500 > to over 1000. It may be that the issue is in our internal thread > handling, but we are seeing the application vanish without a trace when > under heavy load or display some other random weird symptoms. We use > database connection pooling, but we are still looking at over 400 > database connections on occasion which may be the issue. However the > main issue appears to be the lack of thread pooling in Indy - each > connection creates a dedicated thread by default. > > We are currently evaluating other TCP/IP components for this > application. > > You may never hit this level of abuse, but it has caught us out badly. > > Stephen > > > -----Original Message----- > From: Eric Tishler [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 21 July 2004 7:35 a.m. > To: NZ Borland Developers Group - Delphi List > Subject: RE: [DUG] Back with a question about good socket components > > I wil have to look into Indy. We are running D6, but perhaps it is a > newer version of Indy we have. I will need to look into this further. > > In answer to your questions: > > 1) It works for the most part, but becomes unreliable under heavy loads. > (This was not designed with scalability in mind) > > 2) That would require a rewrite of complete sections of code. Besides > the architecture uses sockets for a reason, this in not a web based > application. It just happens to use the Internet as a transport > mechanism. (Not a great idea to date) > > Thanks for your response, > > Eric > > Eric Tishler > Software Architect > Resolute Partners, LLC > Phone: 203.271.1122 > Fax: 203.271.1460 > [EMAIL PROTECTED] > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Dennis Chuah > Sent: Tuesday, July 20, 2004 3:25 PM > To: NZ Borland Developers Group - Delphi List > Subject: Re: [DUG] Back with a question about good socket > components > > > Eric > > Indy - don't know which is the latest version, but we use version 9.010 > here > and it is rock solid. Open source with a large following, so you ought > to > be able to get help from discussion groups, etc. No support other than > that > though. ... and like Kylie says, good enough for Borland to include in > Delphi in preference to NetMasters, though, I wouldn't use the old > version > that came bundled with D6. > > A couple of questions I would like you to ask yourself: > > 1. The client/server product obviously works? So why change the > sockets > library? > 2. If you are going to change the sockets library, consider using HTTP > instead - you have a web server application acting as your sockets > server > and your clients communicate with it using HTTP, or SOAP over HTTP. Use > the > WinAPI Inet functions on the client and there is no need to delve into > sockets, etc. > > HTH, > Dennis. > > ----- Original Message ----- > From: "Eric Tishler" <[EMAIL PROTECTED]> > > > > Well, the forum appears to be back up up once again. So I will repeat > my > last question ... > > > > I have inherited a large scale client server system in Delphi. The > original developer was saving money and got the Freeware FPiette package > to > implement socket communication. > > > > Is there a good socket package that anyone here could recommend? This > is > something I am willing to pay for since I am looking for a package with > a > solid reputation that includes technical support. > > > > I need this for Delphi 6. > > > > Good to be back, > > > > Eric > > > > _______________________________________________ > > Delphi mailing list > > [EMAIL PROTECTED] > > http://ns3.123.co.nz/mailman/listinfo/delphi > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > Disclaimer : This communication contains information that is confidential > and the copyright of ensynergy Limited or a third party. If you are not > the intended recipient of this communication please delete and destroy all > copies and telephone ensynergy Limited on +64 9 3551591 immediately. If > you are the intended recipient of this communication you should not copy, > disclose or distribute this communication without the authority of > ensynergy Limited. Any views expressed in this communication are those of > the individual sender, except where the sender specifically states them to > be the views of ensynergy Limited. Except as required by law, ensynergy > Limited does not represent, warrant and/or guarantee that the integrity of > this communication has been maintained nor that the communication is free > of errors, virus, interception or interference. > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi > > > > _______________________________________________ > Delphi mailing list > [EMAIL PROTECTED] > http://ns3.123.co.nz/mailman/listinfo/delphi _______________________________________________ Delphi mailing list [EMAIL PROTECTED] http://ns3.123.co.nz/mailman/listinfo/delphi
