Den 2016-01-21 kl. 11:30, skrev Simon Slavin: > On 21 Jan 2016, at 9:44am, Daniel Polski <daniel at agelektronik.se> wrote: > >> The Webserver/PHP can process up to 16 requests simultanuously and will >> share one database connection among all instances. >> The process for each request is: >> >> * Use PHP's PDO extension to open a persistent (shared among all instances) >> connection to the database >> -> In the background PHP will only open the database once and then use >> this connection forever > You have a persistent PHP process on the server ? How are you limiting this > to 16 simultaneous connections ? I'm not saying any of your procedure is > wrong, I'm just curious about how it is done under (presumably) Apache.
PHP is running in fastcgi mode, in combination with a lightttp server. This lighttp server always starts 16 instances of the PHP daemon - once a request arrives it passes a request to one of the PHP processes. >> PRAGMA journal_mode = WAL; > Unlike the other two PRAGMAs which do their job you don't need this line. > Once the database is in WAL mode that fact is saved in the file. It won't > change unless you intentionally switch it to something else. We actually can't be sure that the database is already in WAL mode. Checking if the WAL mode is enabled would also require a query, so enabling it (when it's already enabled) is therefore more efficient in terms of query count as far as we understand. >> * If a query fails, due to a busy timeout or locked database (what may occur >> in situations of high system load) the query is retried 10 times, with a >> 100ms sleep between the retries > This is less efficient than PHP/SQLite's own busy processing. Figure out > what you want the total retry to be (probably ten seconds or so) and use that > figure for the timeout setting: > > PRAGMA busy_timeout = 10 * 1000; > > then just take the first _LOCKED or _BUSY as a failure. We already tried that, but that doesn't seem to have any effect. If it fails locked or busy the timeout doesn't seem to make any difference. (This may as well be a quirks of PHP on top of it) >> * At the end of a request, the database is left open (i.e. no disconnect is >> done) in order to maintain the persistent database connection > I am inferring that your queries are executed in one command i.e. exec() or > execute() rather than _prepare,_step,_finalize. We don't really know what PHP internally does, we just execute a single call to "query" the database object.
