"Ron Arts" <r...@arts-betel.org> schrieb im Newsbeitrag news:4adac5c1.5010...@arts-betel.org...
> Then my program opens a socket, and starts accepting connections, > those connections are long lasting, and send messages that need > a fast reply. Many of the messages result in messages being send > to all other clients. The messages require on average 10 lookups > in the memory db, each by oid. Is the "socket-listener-thread" already decoupled from the thread which hosts your sqlite-connection-handle? If not done already, you should try it (that will not speedup the sqlite-performance, but the overall-performance of your "broadcasting-dispatcher-app"). Additionally you should decouple the "sqlite-thread" also from the "reply-sender-threads" (placing the sqlite-query-results in some structures, where the sender-threads are able to find them). That would ensure, that the sqlite-engine can always run fullspeed, not waiting for potentially "slow, or blocking socket-transfers". In such a design you could also try another thing, which maybe speeds up your selects - meaning, maybe "oID- aggregation" can help. If you receive in your socket-listener-thread approx. 50000 requests per second (and nothing will intermit this receiver-thread now, since sqlite-queries run elsewhere) ... then we talk about 50 incoming messages per milisecond. Now, since the sqlite-thread is running elsewhere already ... why not aggregate the incoming oIDs in a comma- separated list (in a simple charbuffer, shared with the sqlite-thread - and flagged with a "next-job-descriptor"). Each 1 msec (to keep the latency low), you should end gathering oIDs in such a "next-job" charbuffer and set the finalized-flag in the job-descriptor-structure (after that you could start gathering oIDs in your listener-thread on a different charbuf-allocation immediately). The sqlite-thread should look for new, flagged as "ready to proceed" charbuffers on its own, and start its work in a more "aggregated fashion" then - and maybe the engine-overhead gets a bit reduced, if sqlite now performs *one* (larger) select (only each 1 msec), but returning more than only one single record in its step-loop then. i.e. per: Select * from Table Where oID In YourGathered_IDList Just an idea - I've not yet tested here, if the throughput would be better this way instead of performing single-record- selects only ... you probably lose the advantage of the precompiled "single-record-statement", but could gain over all, as soon as you reach the step-loop, which does then more than just one record with probably less overhead overall. Maybe that worth' a try. Olaf _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
