Alex, Thankyou for the comments. I use non-blocking fd's also but implement multiple threads to take advantage of multiple processor servers. Since threads carry quite a bit of baggage your single thread approach would probably be superior on a single processor machine.
It has been experience that a well conceived single thread process gives the best performance on a single processor, as one would expect. I would hand out my code except that the whole things incorporates extra processors such as an embedded server page processor and and compiler plus a security shell and would be a handful to maintain and document in great detail but if you are interested in chunks of code contact me. Alex Katebi wrote: > John, > > My server uses epoll( ) and runs non-blocking in a single thread. I did > some google and found out that people who need a very fast server that is > highly scalable are using this model. non-blocking seems to be more > complicated at first glance but it actually makes the server design much > simpler. I am planning to release my code as open source when it is more > complete. > > Thanks, > -Alex > > On Tue, Jun 10, 2008 at 8:48 PM, John Stanton <[EMAIL PROTECTED]> wrote: > >> We use an application server I wrote which handles HTTP, serves file and >> has embedded Sqlite for the RPCs. The RPC can deliver its result either >> in XML for widely distributed applications or as JSON if it is >> responding to a WWW browser in AJAX mode. >> >> We keep a local library of SQL RPCs so that SQl never appears on the >> network and we have immunity from injection attacks. It also means that >> we can cache compiled SQL, a useful performance win. >> >> We use the Expat parser in remote programs using the XML format. A >> wrapper makes it a verifying parser to ensure well formed XML. >> >> The server is multi threaded and maintains a pool of live threads so it >> can respond quickly and assign multiple threads to one browser >> connection. Shared cache in Sqlite and some extra caching to maintain >> multiple open databases and results makes Sqlite behave like a simple to >> use enterprise DB server, but without the overhead of extra processes. >> We use mutexes for synchronization, set up as read and write locks and >> avoid the POSIX file locks. >> >> We installed Javascript as a procedural language to be used by Sqlite >> instead of PL/SQL but that is not a great success (v. slow) and we are >> going to experiment with using Python. >> >> Based on our experience you should be very happy with your Sqlite based >> RPC capability. >> >> Alex Katebi wrote: >>> John & John, >>> >>> Actually my API used to be XML using SCEW a DOM like XML parser that >> uses >>> Expat. >>> >>> For my particular application RPC made more sense to me. What could be >>> easier than a function call? Another advantage was that I did not have to >>> create any functions. I am just using SQLite's C API. Now the users of my >>> application can query any table on the server side using select. Since my >>> application is a network server, and network debugging capability is >>> crucial. >>> The only ugliness is that select locks the tables. I wish D. Hipp would >> give >>> us an option for pStmt to create a temporary table of the select result >> set >>> and delete that temp table after finalize automatically. This way a >> client >>> can sit on a prepare/step for a long time. >>> >>> I solved the endian issue pretty easy by sending the type code. >>> >>> Thanks, >>> -Alex >>> >>> >>> On Tue, Jun 10, 2008 at 3:07 PM, John Elrick <[EMAIL PROTECTED]> >>> wrote: >>> >>>> Alex Katebi wrote: >>>>> Yes I need to do it as 8 byte buffer. Convert the endianess to the >>>> network >>>>> then back to host for 8 byte integer. >>>>> I think XML is great for command validation and CLI auto typing, help >>>> etc. >>>>> Besides parsing issue, XML can not handle binary data directly. >>>>> >>>> As John pointed out, XML is not intended to handle binary data >>>> directly. We use XML as a transfer medium for binary data and simply >>>> base64 encode it before encapsulation. >>>> >>>> >>>> John Elrick >>>> Fenestra Technologies >>>> _______________________________________________ >>>> sqlite-users mailing list >>>> sqlite-users@sqlite.org >>>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >>>> >>> _______________________________________________ >>> sqlite-users mailing list >>> sqlite-users@sqlite.org >>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> _______________________________________________ >> sqlite-users mailing list >> sqlite-users@sqlite.org >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users