In article ,
Jérémy JUST wrote:Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3. Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui dou blait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tand is
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
In article <20070617153046.21ec6...@norbert.jejust.info>,
Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3. Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui dou blait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tand is
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
In article ,
Jérémy JUST wrote:Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3. Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui dou blait
presque la RAM utilisée et donnait des performances proches de celles
Postgresql.
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tand is
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Le Mon, 18 Jun 2007 07:05:50 -0000,Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexité
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par seco nde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST
Le Mon, 18 Jun 2007 07:05:50 -0000,
Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexité
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par seco nde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.
Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST <jeremy_j...@netcourrier.com>
Le Mon, 18 Jun 2007 07:05:50 -0000,Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne peux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexité
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par seco nde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des locks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST
On 18 juin, 09:49, Jérémy JUST wrote:Le Mon, 18 Jun 2007 07:05:50 -0000,Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne p eux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexit é
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par se conde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des loc ks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.Tu ne fais que reporter le problème sur la SGBD, mais comment crois -tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST
(Désolé le message est parti tout seul)....
On 18 juin, 09:49, Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
Le Mon, 18 Jun 2007 07:05:50 -0000,
Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne p eux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexit é
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par se conde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.
Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des loc ks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois -tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST <jeremy_j...@netcourrier.com>
(Désolé le message est parti tout seul)....
On 18 juin, 09:49, Jérémy JUST wrote:Le Mon, 18 Jun 2007 07:05:50 -0000,Voyant ces chiffres, j'ai du mal à imaginer que des
entrées/sorties de parkings puissent saturer l'un ou l'autre des
systèmes.
Tu serais surpris de tout ce qui se passe lorsque tu entres ta carte
de parking .....
C'est un système temps réel beaucoup plus compliqué que tu ne p eux
l'imaginer.
Je veux bien te croire, mais pourrais-tu nous donner une estimation
du nombre d'écritures et de lectures par seconde? Et de la complexit é
des requêtes?
Je te propose un système qui peut réaliser 500 écritures par se conde
(à la louche; je ne garantis évidemment rien). Il y a bien entendu des
cas de la vie courante qui ont besoin de plus; j'ignorais que la
gestion de parkings entrait dans cette catégorie.Par contre, utiliser un SGBD te soulagerait de bien des soucis pour
les verrouillages et le partage entre processus.
Je ne suis pas d'accord, même pour une SGBD tu as a gérer des loc ks
exclusifs ou non.
Oui, mais le SGBD lui-même te fournit des outils pour ça. Et leur
mise en oeuvre fait tellement partie de la bonne utilisation du SGBD
qu'on ne se pose que rarement des question à leur sujet.Tu ne fais que reporter le problème sur la SGBD, mais comment crois -tu
qu'elle gère les lock de tables ?
Dans le cadre d'un projet de développement, ce n'est pas mon
problème, puisque tout est fait pour que ça marche simplement et
efficacement.
Cette question est plus de l'ordre de la culture personnelle. Et pour
être honnête, je n'en sais rien (je note qu'il faudra creuser ça à
l'occasion).
--
Jérémy JUST
(Désolé le message est parti tout seul)....
Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui arrive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se peut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + décision
+ écriture ce qui conduit à un lock de ~ 1sec/évènement important
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvoir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le système de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un embouteillage
au niveau des sémaphores, à ce moment là, tous les processus partent
en timeout.
[...]
Est-ce que j'ai bon ???
Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui arrive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se peut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + décision
+ écriture ce qui conduit à un lock de ~ 1sec/évènement important
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvoir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le système de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un embouteillage
au niveau des sémaphores, à ce moment là, tous les processus partent
en timeout.
[...]
Est-ce que j'ai bon ???
Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui arrive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se peut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + décision
+ écriture ce qui conduit à un lock de ~ 1sec/évènement important
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvoir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le système de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un embouteillage
au niveau des sémaphores, à ce moment là, tous les processus partent
en timeout.
[...]
Est-ce que j'ai bon ???
À (at) Fri, 15 Jun 2007 09:45:07 -0000,
Sébastien Cottalorda écrivait (wrote):Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui ar rive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se pe ut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + déci sion
+ écriture ce qui conduit à un lock de ~ 1sec/évènement importa nt
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvo ir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le systèm e de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un emboutei llage
au niveau des sémaphores, à ce moment là, tous les processus part ent
en timeout.
[...]Est-ce que j'ai bon ???
Le temps de lock annoncé (1s) me semble énorme. Que fait votre
processus pendant cette longue seconde ? De plus, je ne comprends pas
pourquoi il y aurait (inter)blocage. Quelles sont les données
réellement partagées par tous les processus ? Lorsque je change le nom
d'un client, cela n'a aucun impact sur la contrôle d'accès (sauf dans
le très rare cas où c'est ce client spécifiquement qui cherche à
entrer).
J'ai l'impression que vous n'avez pas choisi la granularité de vos
données (et donc des verrous) assez finement.
Tel que vous décrivez votre besoin, une base de données permettant de
faire des transactions ou des locks locaux (par ligne par exemple) me
semblerait tout à fait adapatée...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 15 Jun 2007 09:45:07 -0000,
Sébastien Cottalorda <scottalo...@libello.com> écrivait (wrote):
Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui ar rive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se pe ut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + déci sion
+ écriture ce qui conduit à un lock de ~ 1sec/évènement importa nt
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvo ir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le systèm e de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un emboutei llage
au niveau des sémaphores, à ce moment là, tous les processus part ent
en timeout.
[...]
Est-ce que j'ai bon ???
Le temps de lock annoncé (1s) me semble énorme. Que fait votre
processus pendant cette longue seconde ? De plus, je ne comprends pas
pourquoi il y aurait (inter)blocage. Quelles sont les données
réellement partagées par tous les processus ? Lorsque je change le nom
d'un client, cela n'a aucun impact sur la contrôle d'accès (sauf dans
le très rare cas où c'est ce client spécifiquement qui cherche à
entrer).
J'ai l'impression que vous n'avez pas choisi la granularité de vos
données (et donc des verrous) assez finement.
Tel que vous décrivez votre besoin, une base de données permettant de
faire des transactions ou des locks locaux (par ligne par exemple) me
semblerait tout à fait adapatée...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 15 Jun 2007 09:45:07 -0000,
Sébastien Cottalorda écrivait (wrote):Le noyau, selon mes mesures locke au maximum 1 sec le(s) segment(s)
pour chaque évènement.
Hélas, il n'est pas tout seul pour plusieurs raisons:
* Il y a plusieurs parkings à gérer : les évènements lui ar rive en
parallèle, en effet, sur le nombre de borne entrée/sortie, il se pe ut
tout a fait qu'il y ait plusieurs véhicule souhaita,t entrer ou sortie
simultannément.
* Chque prise de décision doit être atomique : lecture + déci sion
+ écriture ce qui conduit à un lock de ~ 1sec/évènement importa nt
(0,00... sec pour des évènements peu importants),
* Le noyau n'est pas tout seul à écrire dans les segments de
mémoire, même si cela est vrai dans 98% des cas, il faut bien pouvo ir
modifier les données permettant le contrôle d'accès : le nom d'un
client, ses données de facturation, ou tout bêtement modifier les
paramètres des équipements sans avoir à relancer tout le systèm e de
contrôle d'accès (on peux faire mieux que Windows n'est-ce pas ?)
Lorsque le système est très chargé, je fini par avoir un emboutei llage
au niveau des sémaphores, à ce moment là, tous les processus part ent
en timeout.
[...]Est-ce que j'ai bon ???
Le temps de lock annoncé (1s) me semble énorme. Que fait votre
processus pendant cette longue seconde ? De plus, je ne comprends pas
pourquoi il y aurait (inter)blocage. Quelles sont les données
réellement partagées par tous les processus ? Lorsque je change le nom
d'un client, cela n'a aucun impact sur la contrôle d'accès (sauf dans
le très rare cas où c'est ce client spécifiquement qui cherche à
entrer).
J'ai l'impression que vous n'avez pas choisi la granularité de vos
données (et donc des verrous) assez finement.
Tel que vous décrivez votre besoin, une base de données permettant de
faire des transactions ou des locks locaux (par ligne par exemple) me
semblerait tout à fait adapatée...
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
On 17 juin, 16:35, (Marc Espie) wrote:In article ,
Jérémy JUST wrote:La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à ton
patron que tu as perdu de l'argent pour une histoire de perfomance ?
On 17 juin, 16:35, e...@lain.home (Marc Espie) wrote:
In article <20070617153046.21ec6...@norbert.jejust.info>,
Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à ton
patron que tu as perdu de l'argent pour une histoire de perfomance ?
On 17 juin, 16:35, (Marc Espie) wrote:In article ,
Jérémy JUST wrote:La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, tandis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à ton
patron que tu as perdu de l'argent pour une histoire de perfomance ?
Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référence
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservation de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidentiel
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référence
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservation de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidentiel
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référence
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservation de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidentiel
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
In article ,
Sébastien Cottalorda wrote:On 17 juin, 16:35, (Marc Espie) wrote:In article ,
Jérémy JUST wrote:La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, t andis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu 'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Les systemes `temps reels' qui supportent des millions d'enregistrements
ont interet a avoir BEAUCOUP de memoire, ou des choses tres simples a
stocker, et de bonnes garanties quant a la vitesse du swap, sinon ils
auront du mal a etre temps reel...
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à t on
patron que tu as perdu de l'argent pour une histoire de perfomance ?
Mon patron, il ne va rien penser. Avant de raconter N'IMPORTE QUOI,
il faut lire la TOTALITE du message. On parle ici de remplir une table
de 3 millions d'enregistrements a partir d'un fichier tabule.
Que je sache, si ton systeme plante apres la 999e transaction, ton fichier
tabule est toujours la, et tu vas pouvoir regarder ce qu'il en est...
voire carrement recommencer, si tu etais juste en train d'amorcer une
table a partir d'un fichier.
C'est quand meme un gros classique de l'utilisation des bases de donnees:
on utilise le transactionnel pur en live. Par contre, lorsqu'il s'agit
de convertir des batch de donnees, on peut souvent se permettre d'y
aller par gros lots, toutes precautions prises par ailleurs.
Et, de toutes facons, quelle que soit ta base, tu fais des backups
regulierement, et si c'est vraiment un truc critique ou tu ne peux
pas te permettre de perdre une transaction, tu as un systeme fortement
redondant a tous les niveaux (log papier, double base, etc). Faire les
transactions une par une, meme avec le plus beau systeme informatique
du monde, ne te protegera jamais contre un incendie.
In article <1182150551.303240.209...@o61g2000hsh.googlegroups.com>,
Sébastien Cottalorda <scottalo...@libello.com> wrote:
On 17 juin, 16:35, e...@lain.home (Marc Espie) wrote:
In article <20070617153046.21ec6...@norbert.jejust.info>,
Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, t andis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu 'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Les systemes `temps reels' qui supportent des millions d'enregistrements
ont interet a avoir BEAUCOUP de memoire, ou des choses tres simples a
stocker, et de bonnes garanties quant a la vitesse du swap, sinon ils
auront du mal a etre temps reel...
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à t on
patron que tu as perdu de l'argent pour une histoire de perfomance ?
Mon patron, il ne va rien penser. Avant de raconter N'IMPORTE QUOI,
il faut lire la TOTALITE du message. On parle ici de remplir une table
de 3 millions d'enregistrements a partir d'un fichier tabule.
Que je sache, si ton systeme plante apres la 999e transaction, ton fichier
tabule est toujours la, et tu vas pouvoir regarder ce qu'il en est...
voire carrement recommencer, si tu etais juste en train d'amorcer une
table a partir d'un fichier.
C'est quand meme un gros classique de l'utilisation des bases de donnees:
on utilise le transactionnel pur en live. Par contre, lorsqu'il s'agit
de convertir des batch de donnees, on peut souvent se permettre d'y
aller par gros lots, toutes precautions prises par ailleurs.
Et, de toutes facons, quelle que soit ta base, tu fais des backups
regulierement, et si c'est vraiment un truc critique ou tu ne peux
pas te permettre de perdre une transaction, tu as un systeme fortement
redondant a tous les niveaux (log papier, double base, etc). Faire les
transactions une par une, meme avec le plus beau systeme informatique
du monde, ne te protegera jamais contre un incendie.
In article ,
Sébastien Cottalorda wrote:On 17 juin, 16:35, (Marc Espie) wrote:In article ,
Jérémy JUST wrote:La différence principale était au moment du remplissage des
structures: il suffisait de quelques minutes pour remplir le hash avec
les 3 millions d'enregistrements, à partir d'un fichier tabulé, t andis
qu'il fallait une à deux heures pour Postgresql.
Et encore, c'etait avec du postgresql... sur certains types de tables,
je soupconne que sqlite va nettement plus vite, vu qu'il y a moins de
transferts a faire.
D'une manière ou d'une autre, vous ne m'enlèverez pas de l'idée qu 'un
système temps réel basé sur des partages en mémoire est beaucoup plus
performant que tous les systèmes basés sur des fichiers à plats
(indexés ou pas).
Les systemes `temps reels' qui supportent des millions d'enregistrements
ont interet a avoir BEAUCOUP de memoire, ou des choses tres simples a
stocker, et de bonnes garanties quant a la vitesse du swap, sinon ils
auront du mal a etre temps reel...
Et aussi, penser a virer l'autocommit, et a faire des commits manuels
toutes les 1000 ou 2000 transactions... Ca fait facilement un facteur
dix d'ecart sur la vitesse d'ecriture.
Super, et que se passe t'il si ton système plante au bout de la 999
ème transaction ? ou de la 1999 ième, comment vas-tu expliquer à t on
patron que tu as perdu de l'argent pour une histoire de perfomance ?
Mon patron, il ne va rien penser. Avant de raconter N'IMPORTE QUOI,
il faut lire la TOTALITE du message. On parle ici de remplir une table
de 3 millions d'enregistrements a partir d'un fichier tabule.
Que je sache, si ton systeme plante apres la 999e transaction, ton fichier
tabule est toujours la, et tu vas pouvoir regarder ce qu'il en est...
voire carrement recommencer, si tu etais juste en train d'amorcer une
table a partir d'un fichier.
C'est quand meme un gros classique de l'utilisation des bases de donnees:
on utilise le transactionnel pur en live. Par contre, lorsqu'il s'agit
de convertir des batch de donnees, on peut souvent se permettre d'y
aller par gros lots, toutes precautions prises par ailleurs.
Et, de toutes facons, quelle que soit ta base, tu fais des backups
regulierement, et si c'est vraiment un truc critique ou tu ne peux
pas te permettre de perdre une transaction, tu as un systeme fortement
redondant a tous les niveaux (log papier, double base, etc). Faire les
transactions une par une, meme avec le plus beau systeme informatique
du monde, ne te protegera jamais contre un incendie.
À (at) Mon, 18 Jun 2007 10:57:06 -0000,
Sébastien Cottalorda écrivait (wrote):
[...]Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référen ce
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservat ion de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidenti el
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
Il faut toujours minimiser la durée du passage en section critique
(les instructions entre la mise en place du verrou et sa
libération). Tel qu'exposé, la prise de vue, l'analyse de la photo
pour retrouver le numéro, la saisie du code, etc. ne sont pas en
section critique. Seul la recherche du code ou du numéro devraient
être dans la section critique. Une recherche dans une table de
hachage, c'est bien moins que 1s ! Ensuite, l'ordre d'ouverture se
fait en dehors de la section critique.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 18 Jun 2007 10:57:06 -0000,
Sébastien Cottalorda <scottalo...@libello.com> écrivait (wrote):
[...]
Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référen ce
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservat ion de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidenti el
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
Il faut toujours minimiser la durée du passage en section critique
(les instructions entre la mise en place du verrou et sa
libération). Tel qu'exposé, la prise de vue, l'analyse de la photo
pour retrouver le numéro, la saisie du code, etc. ne sont pas en
section critique. Seul la recherche du code ou du numéro devraient
être dans la section critique. Une recherche dans une table de
hachage, c'est bien moins que 1s ! Ensuite, l'ordre d'ouverture se
fait en dehors de la section critique.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Mon, 18 Jun 2007 10:57:06 -0000,
Sébastien Cottalorda écrivait (wrote):
[...]Je suis en train de réduire ce temps en dissociant la prise de photo
et le temps réel afin d'augmenter les performances.
Pour se faire, je vais donner au "photographe" (le programme qui
prends les photos), à chaque ordre de prise de photo, une référen ce
unique afin qu'il mette ensuite à jour, lui même, d'une manière
asynchrone, la fiche client.
Pendant ce temps là le lock aura été libéré par le contrôle d'accès,
et la barrière recevra son ordre d'ouverture.
J'escompte une prise de décision aux alentours de 0,4 sec
En ce qui concerne le contenus des segments de mémoire, celui qui me
pose problème est celui contenant la liste des codes d'accès.
En effet, pour qu'un client puisse entrer ou sortir du système, il
faut l'une des 2 choses suivantes (ou bien les 2)
* Que le client possède une immatriculation que le système
connait,
* Que le client saisisse sur l'écran tactile, son code d'accès,
unique, aléatoire, qui lui a été attribué lors de sa réservat ion de
place.
Que ce soit avec l'une ou l'autre méthode, le contrôle d'accès va:
o locker le segment de mémoire indexé sur les codes d'accès
* si le système est sollicité par le biais d'une lecture
d'immatriculation, le contrôle d'accès va parcourir l'ensemble du
segment afin de rechercher la présence de cette immatriculation. S'il
la trouve -> il va évaluer si le client peut entrer ou pas et donner
l'ordre d'ouverture ou de refus.
* si le système est sollicité par saisie du code confidenti el
(sur un écran tactile), le contrôle d'accès va prendre une photo pour
attester le passage, puis il va vérifier que le code saisie permet
l'entrée ou la sortie. Ensuite il va donner l'ordre d'ouverture d ela
barrière ou bien mentionner un refus sur l'IHM.
o libérer le lock sur le segment de mémoirte contenant les codes
C'est le deuxième cas qui me pose problème actuellement, car il faut
que j'attende ~1 sec que la photo soit prise etc...
En bref le segment qui me pose des problèmes d'accès concurrent est
celui qui est indexé par *code* et qui contient toutes les
informations utiles à la prise de décision du contrôle d'accès.
Je pense que mes segments sont minimalistes.
Cependant, je ne peux pas faire autrement que de locker *l'ensemble*
du segment (donc l'ensemble des fiches client) à chaque fois que le
système prends une décision ?
Il faut toujours minimiser la durée du passage en section critique
(les instructions entre la mise en place du verrou et sa
libération). Tel qu'exposé, la prise de vue, l'analyse de la photo
pour retrouver le numéro, la saisie du code, etc. ne sont pas en
section critique. Seul la recherche du code ou du numéro devraient
être dans la section critique. Une recherche dans une table de
hachage, c'est bien moins que 1s ! Ensuite, l'ordre d'ouverture se
fait en dehors de la section critique.
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>