J'ai developp=E9 un contr=F4le d'acc=E8s pour g=E9rer les entr=E9es/sorties=
de
parkings.
Le noyau du syst=E8me (qui doit =EAtre temps r=E9el) travaille avec le
module IPC::Shareable pour acc=E9der tr=E8s rapidement aux donn=E9es mises
en m=E9moire.
Lorsqu'il y acc=E8de, il locke le(s) segment(s) de m=E9moire partag=E9e
gr=E2ce =E0 un LOCK_EX afin que les donn=E9es qu'il va lire ne soient pas
corrompues durant sa prise de d=E9cision.
Seulement voil=E0 durant le lapse de temps, tous les petits programmes
"clients" qui sont cens=E9 lire le contenue de la m=E9moire afin d'en
afficher le contenue se trouvent fig=E9s jusqu'=E0 la lib=E9ration du lock
ce qui peut =EAtre assez g=E9nant.
Je ne peux pas tous les mettre en LOCK_SH|LOCK_NB sinon ils ne lisent
m=EAme pas le segment puisque cela rend la main tout de suite.
Aussi, je me demandais si le noyau utilisait un LOCK_SH est-ce que
cela ne serait pas mieux ?
En fait, je voudrais id=E9alement que le programme principal puisse lire
et =E9crire, et que les programmes clients puissent seulement lire.
Est-ce que le LOCK_SH pourrait me tirer d'affaire ?
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une base de données?
-- Désormais, pour les nations et pour les peuples, une goutte de pétrole a la valeur d'une goutte de sang. Georges Clémenceau.
Paul Gaborit
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une base de données?
Si l'impératif est d'obtenir de grandes performances (ce qui justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
Ce que je ne comprends pas dans la problématique exposée, c'est que, s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage lors de l'écriture, il lui suffit de préparer toutes ses données à l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui modifie les données) et de les écrire d'un seul coup (durant un LOCK).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac <eflorac@imaginet.fr> écrivait (wrote):
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une base de
données?
Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
Ce que je ne comprends pas dans la problématique exposée, c'est que,
s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire
des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage
lors de l'écriture, il lui suffit de préparer toutes ses données à
l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui
modifie les données) et de les écrire d'un seul coup (durant un LOCK).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Le Fri, 15 Jun 2007 07:51:37 +0000, Sébastien Cottalorda a écrit :
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une base de données?
Si l'impératif est d'obtenir de grandes performances (ce qui justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
Ce que je ne comprends pas dans la problématique exposée, c'est que, s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage lors de l'écriture, il lui suffit de préparer toutes ses données à l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui modifie les données) et de les écrire d'un seul coup (durant un LOCK).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
Sébastien Cottalorda
On 15 juin, 11:06, Paul Gaborit wrote:
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une bas e de données?
Si l'impératif est d'obtenir de grandes performances (ce qui justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
C'est le cas. Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Ce que je ne comprends pas dans la problématique exposée, c'est que, s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage lors de l'écriture, il lui suffit de préparer toutes ses données à l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui modifie les données) et de les écrire d'un seul coup (durant un LOCK).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
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.
C'est pourquoi, au niveau des programmes clients n'effectuant qu'une lecture, j'ai également ajouté une tempo au delà de laquelle il meurent.
En fait j'utilise LOCK_EX pour les processus chargés de lire et *d'écrire*, et LOCK_SH pour les processus en lecture + mode bloquant et LOCK_SH|LOCK_NB pour les programmes chargés uniquement de l'affichage dont on peut se passer (puisqu'ils seront sollicités un peu plus tard : si on perd un affichage, ce n'est pas dramatique).
Est-ce que j'ai bon ???
merci de votre temps et de votre aide.
On 15 juin, 11:06, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac <eflo...@imaginet.fr> écrivait (wrote):
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une bas e de
données?
Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)
Ce que je ne comprends pas dans la problématique exposée, c'est que,
s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire
des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage
lors de l'écriture, il lui suffit de préparer toutes ses données à
l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui
modifie les données) et de les écrire d'un seul coup (durant un LOCK).
--
Paul Gaborit - <http://perso.enstimac.fr/~gaborit/>
Perl en français - <http://perl.enstimac.fr/>
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.
C'est pourquoi, au niveau des programmes clients n'effectuant qu'une
lecture, j'ai également ajouté une tempo au delà de laquelle il
meurent.
En fait j'utilise LOCK_EX pour les processus chargés de lire et
*d'écrire*, et LOCK_SH pour les processus en lecture + mode bloquant
et LOCK_SH|LOCK_NB pour les programmes chargés uniquement de
l'affichage dont on peut se passer (puisqu'ils seront sollicités un
peu plus tard : si on perd un affichage, ce n'est pas dramatique).
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une bas e de données?
Si l'impératif est d'obtenir de grandes performances (ce qui justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
C'est le cas. Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Ce que je ne comprends pas dans la problématique exposée, c'est que, s'il n'y a qu'un seul écrivain, il n'y a que lui qui a besoin de faire des locks et uniquement lorsqu'il écrit. Pour éviter de long blocage lors de l'écriture, il lui suffit de préparer toutes ses données à l'avance (il peut le faire sans lock puisqu'il n'y a que lui qui modifie les données) et de les écrire d'un seul coup (durant un LOCK).
-- Paul Gaborit - <http://perso.enstimac.fr/~gaborit/> Perl en français - <http://perl.enstimac.fr/>
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.
C'est pourquoi, au niveau des programmes clients n'effectuant qu'une lecture, j'ai également ajouté une tempo au delà de laquelle il meurent.
En fait j'utilise LOCK_EX pour les processus chargés de lire et *d'écrire*, et LOCK_SH pour les processus en lecture + mode bloquant et LOCK_SH|LOCK_NB pour les programmes chargés uniquement de l'affichage dont on peut se passer (puisqu'ils seront sollicités un peu plus tard : si on perd un affichage, ce n'est pas dramatique).
Est-ce que j'ai bon ???
merci de votre temps et de votre aide.
Mark Clements
Sébastien Cottalorda wrote:
On 15 juin, 11:06, Paul Gaborit wrote:
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Sinon, comment puis-je régler ce problème ? Utilise un système adapté pour gérer les données, comme une base de
données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
C'est le cas. Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Est-ce que t'as regardé quelque chose un peu plus high-level que la memoire partagé, par exemple BerkeleyDB?
Normalement c'est performant et peut gèrer le locking etc soi-même.
Marl
Jérémy JUST
Le Fri, 15 Jun 2007 09:45:07 -0000,
Utilise un système adapté pour gérer les données, comme une base de données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées. C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions d'enregistrements), la différence n'est pas si franche. J'ai comparé deux systèmes: - un hash maintenu en mémoire par un démon en Perl, à qui on adressait des requêtes par un socket (client en Perl), - une bête table sous Postgresql, indexée.
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 doublait 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é, tandis qu'il fallait une à deux heures pour Postgresql.
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. Par contre, utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages et le partage entre processus.
-- Jérémy JUST
Le Fri, 15 Jun 2007 09:45:07 -0000,
Utilise un système adapté pour gérer les données, comme une base
de données?
Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre
Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions
d'enregistrements), la différence n'est pas si franche. J'ai comparé
deux systèmes:
- un hash maintenu en mémoire par un démon en Perl, à qui on adressait
des requêtes par un socket (client en Perl),
- une bête table sous Postgresql, indexée.
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 doublait
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é, tandis
qu'il fallait une à deux heures pour Postgresql.
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. Par contre,
utiliser un SGBD te soulagerait de bien des soucis pour les
verrouillages et le partage entre processus.
Utilise un système adapté pour gérer les données, comme une base de données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées. C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions d'enregistrements), la différence n'est pas si franche. J'ai comparé deux systèmes: - un hash maintenu en mémoire par un démon en Perl, à qui on adressait des requêtes par un socket (client en Perl), - une bête table sous Postgresql, indexée.
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 doublait 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é, tandis qu'il fallait une à deux heures pour Postgresql.
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. Par contre, utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages et le partage entre processus.
-- Jérémy JUST
Emmanuel Florac
Le Sun, 17 Jun 2007 15:30:46 +0200, Jérémy JUST a écrit :
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. Par contre, utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages et le partage entre processus.
C'est bien pour cela que j'en avais parlé :)
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
Le Sun, 17 Jun 2007 15:30:46 +0200, Jérémy JUST a écrit :
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. Par contre,
utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages
et le partage entre processus.
C'est bien pour cela que j'en avais parlé :)
--
Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir
aristocratique de déplaire.
C. Baudelaire.
Le Sun, 17 Jun 2007 15:30:46 +0200, Jérémy JUST a écrit :
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. Par contre, utiliser un SGBD te soulagerait de bien des soucis pour les verrouillages et le partage entre processus.
C'est bien pour cela que j'en avais parlé :)
-- Ce qu'il y a d'enivrant dans le mauvais goût c'est le plaisir aristocratique de déplaire. C. Baudelaire.
espie
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 doublait 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é, 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.
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.21ec6613@norbert.jejust.info>,
Jérémy JUST <jeremy_just@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 doublait
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é, 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.
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.
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 doublait 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é, 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.
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.
Jérémy JUST
Le Sun, 17 Jun 2007 14:35:34 +0000 (UTC),
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.
En plus, gérer manuellement les commits donne une façon simple et propre de réaliser des transactions atomiques. Que des avantages!
-- Jérémy JUST
Le Sun, 17 Jun 2007 14:35:34 +0000 (UTC),
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.
En plus, gérer manuellement les commits donne une façon simple et
propre de réaliser des transactions atomiques. Que des avantages!
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.
En plus, gérer manuellement les commits donne une façon simple et propre de réaliser des transactions atomiques. Que des avantages!
-- Jérémy JUST
Sébastien Cottalorda
On 17 juin, 10:20, Mark Clements wrote:
Sébastien Cottalorda wrote:
On 15 juin, 11:06, Paul Gaborit wrote:
À (at) Fri, 15 Jun 2007 10:24:59 +0200, Emmanuel Florac écrivait (wrote):
Sinon, comment puis-je régler ce problème ? Utilise un système adapté pour gérer les données, comme une b ase de
données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées.
C'est le cas. Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Est-ce que t'as regardé quelque chose un peu plus high-level que la memoire partagé, par exemple BerkeleyDB?
Normalement c'est performant et peut gèrer le locking etc soi-même.
Marl
Salut,
dans le cadre de mon projet, j'utilise également DB Berkeley, mais a un usage non volatile, cad permettant de retrouver les infos après coupure ou redémarrage du serveur.
C'est un système performant, mais basé sur des fichiers, je doute que cette technologie soit plus performante que de la mémoire pure ...
Je n'ai malheureusement pas le temps de vérifier.
On 17 juin, 10:20, Mark Clements <mark.clementsREMOVET...@wanadoo.fr>
wrote:
Sébastien Cottalorda wrote:
On 15 juin, 11:06, Paul Gaborit <Paul.Gabo...@invalid.invalid> wrote:
À (at) Fri, 15 Jun 2007 10:24:59 +0200,
Emmanuel Florac <eflo...@imaginet.fr> écrivait (wrote):
Sinon, comment puis-je régler ce problème ?
Utilise un système adapté pour gérer les données, comme une b ase de
données?
Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)
Est-ce que t'as regardé quelque chose un peu plus high-level que la
memoire partagé, par exemple BerkeleyDB?
Normalement c'est performant et peut gèrer le locking etc soi-même.
Marl
Salut,
dans le cadre de mon projet, j'utilise également DB Berkeley, mais a
un usage non volatile, cad permettant de retrouver les infos après
coupure ou redémarrage du serveur.
C'est un système performant, mais basé sur des fichiers, je doute que
cette technologie soit plus performante que de la mémoire pure ...
Normalement c'est performant et peut gèrer le locking etc soi-même.
Marl
Salut,
dans le cadre de mon projet, j'utilise également DB Berkeley, mais a un usage non volatile, cad permettant de retrouver les infos après coupure ou redémarrage du serveur.
C'est un système performant, mais basé sur des fichiers, je doute que cette technologie soit plus performante que de la mémoire pure ...
Je n'ai malheureusement pas le temps de vérifier.
Sébastien Cottalorda
On 17 juin, 15:30, Jérémy JUST wrote:
Le Fri, 15 Jun 2007 09:45:07 -0000,
Utilise un système adapté pour gérer les données, comme une b ase de données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées. C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions d'enregistrements), la différence n'est pas si franche. J'ai comparé deux systèmes: - un hash maintenu en mémoire par un démon en Perl, à qui on adres sait des requêtes par un socket (client en Perl), - une bête table sous Postgresql, indexée.
Pour une requête sur la clef du hash, le démon en Perl était plus rapide d'un facteur 2 à 3.
Je suis *très majoritairement* dans ce cas de figure.
Pour des requêtes ne portant plus sur la clef du hash, il fallait créer un second hash à côté, ce qui doub lait 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é, tandis qu'il fallait une à deux heures pour Postgresql.
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. Mon problème n'est pas réglé pour autant.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu qu'elle gère les lock de tables ?
-- Jérémy JUST
On 17 juin, 15:30, Jérémy JUST <jeremy_j...@netcourrier.com> wrote:
Le Fri, 15 Jun 2007 09:45:07 -0000,
Utilise un système adapté pour gérer les données, comme une b ase
de données?
Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne
pense pas que la base de données soit adpatées.
C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties
(sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre
Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions
d'enregistrements), la différence n'est pas si franche. J'ai comparé
deux systèmes:
- un hash maintenu en mémoire par un démon en Perl, à qui on adres sait
des requêtes par un socket (client en Perl),
- une bête table sous Postgresql, indexée.
Pour une requête sur la clef du hash, le démon en Perl était plus
rapide d'un facteur 2 à 3.
Je suis *très majoritairement* dans ce cas de figure.
Pour des requêtes ne portant plus sur la
clef du hash, il fallait créer un second hash à côté, ce qui doub lait
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é, tandis
qu'il fallait une à deux heures pour Postgresql.
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.
Mon problème n'est pas réglé pour autant.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu
qu'elle gère les lock de tables ?
Utilise un système adapté pour gérer les données, comme une b ase de données? Si l'impératif est d'obtenir de grandes performances (ce qui
justifierai le partage mémoire entre processus ou threads), je ne pense pas que la base de données soit adpatées. C'est le cas.
Sinon, ce serait rigolo les jours de facture aux entrée et aux sorties (sgbd assez chargé ...)
Pour mon information, tu as fait des tests avec un SGBD genre Postgresql? C'est réellement moins performant que ton système?
Parce que dans mon expérience (table avec deux à trois millions d'enregistrements), la différence n'est pas si franche. J'ai comparé deux systèmes: - un hash maintenu en mémoire par un démon en Perl, à qui on adres sait des requêtes par un socket (client en Perl), - une bête table sous Postgresql, indexée.
Pour une requête sur la clef du hash, le démon en Perl était plus rapide d'un facteur 2 à 3.
Je suis *très majoritairement* dans ce cas de figure.
Pour des requêtes ne portant plus sur la clef du hash, il fallait créer un second hash à côté, ce qui doub lait 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é, tandis qu'il fallait une à deux heures pour Postgresql.
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. Mon problème n'est pas réglé pour autant.
Tu ne fais que reporter le problème sur la SGBD, mais comment crois-tu qu'elle gère les lock de tables ?
