Mutliple threads in one process let me perform load balancing and share the Sqlite cache. Cache sharing can be a big win.
Alex Katebi wrote: > Hi John, > > Yes the negative with the single thread is single CPU utilization. Then > again you can run 4 or more servers for a quad CPU. For security I could > either use SSH Port Forwarding or use a MD5 implementation in my > client/server code. > > Thanks, > -Alex > > > > On Tue, Jun 10, 2008 at 11:25 PM, John Stanton <[EMAIL PROTECTED]> wrote: > >> 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 >> > _______________________________________________ > 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