ciao Paolo
On 06/15/2015 10:50 PM, Paolo Bevilacqua wrote:
I
On Mon, Jun 15, 2015, at 10:16 PM, David Welton wrote:
That is fine when you want to just load global static data.
My objective is to have global variables, that is, they can vary
For now I've achieved this setting prefork values to 1 and running
"httpd -X".
That'll work for a simple demo web server, but won't work at all under
any kind of load.
You need to investigate a data store like Postgres or Redis if you're
going to take what you're doing anywhere beyond a simple experiment.
It is handling up to 20 request per second on a VM, which is fine with
the application objectives.
There is absolutely no need for any database in my application.
<i>Always striving to honor my word and commitments</i>
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
it looks to me a way to concoct a solution by bending the web server
design instead of exploiting it properly.
In fact you also wrote you have a single writer (producer), which I
suppose external to the web server, and the Apache child process works
as consumer. Without locking/synchronization most R/W operation in
memory can be interrupted by the system scheduler and the producer
process be rescheduled for execution after other processes (consumers)
have gained access to the data. Only very basic data would have atomic
R/W and even in that case you might hit portability issues across
different architectures. If you have data that span across multiple
words (a list, a string, an array....) you can be certain that sooner or
later some consumer will access the shared data in an inconsistent state
because the producer had been interrupted while writing them.
DBMS are very efficient for that and they are already atomic when
updating a single table row and have caching mechanisms that would
certainly avoid unnecessary disk accesses when the consumers read the
data. They are much more optimized than you imagine for accessing data
stored on disk. And in case you need locking to update data across
different rows and tables the whole mechanics it's already there
-- Massimo
---------------------------------------------------------------------
To unsubscribe, e-mail: rivet-dev-unsubscr...@tcl.apache.org
For additional commands, e-mail: rivet-dev-h...@tcl.apache.org
