J’ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez OVH et c’est pas une réussite… A chaque fois qu’on s’approche de Tickets, dans cfg par exemple, ça rame à mort, voire ça n’aboutis pas…
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
Je ne suis pas sûr que cela provienne de ce plugin...
Je l'utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)...
Une solution ou un début de piste serait grandement apprécié
Cordialement,
Pascal JPM
De : Benjamin Farrudja [mailto:farouba@gmail.com]
Envoyé : mardi 3 novembre 2009 04:55
À : SPIP Zone
Objet : [SPIP Zone] Lenteur SPIP 2.0.9 [14428] avec Tickets
Salut,
J'ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez
OVH et c'est pas une réussite... A chaque fois qu'on s'approche de Tickets,
dans cfg par exemple, ça rame à mort, voire ça n'aboutis pas...
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
A voir...
Benjamin
__________ Information provenant d'ESET NOD32 Antivirus, version de la base
des signatures de virus 4568 (20091103) __________
Le message a été vérifié par ESET NOD32 Antivirus.
Je ne suis pas sûr que cela provienne de ce plugin…
Je l’utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)…
Une solution ou un début de piste serait grandement apprécié
Envoie moi un accès admin à SPIP, je peux jeter un oeil rapide si tu veux !
Cédric
Je ne suis pas sûr que cela provienne de ce plugin…
Je l’utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)…
Une solution ou un début de piste serait grandement apprécié
Cordialement,
Pascal JPM
Je pense pas que ça soit un problème l’hébergement mutu d’OVH, urtout si t’as une sql privée avec connexions illimités… A moins d’avoir vraiment une usine à gaz ou des truc mal codés. Enfin en tout cas j’espère !
Lorsque je coupe le plugin Tickets tout va bien, du coup j’imagine que c’est à cause de lui.
Benjamin
De : Benjamin Farrudja [mailto:farouba@gmail.com]
Envoyé : mardi 3 novembre 2009 04:55
À : SPIP Zone
Objet : [SPIP Zone] Lenteur SPIP 2.0.9 [14428] avec Tickets
Salut,
J’ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez
OVH et c’est pas une réussite… A chaque fois qu’on s’approche de Tickets,
dans cfg par exemple, ça rame à mort, voire ça n’aboutis pas…
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
A voir…
Benjamin
__________ Information provenant d’ESET NOD32 Antivirus, version de la base
des signatures de virus 4568 (20091103) __________
Le message a été vérifié par ESET NOD32 Antivirus.
Le problème d’hébergement mutualisé chez OVH est général et ne dépend pas de ce plugin (ticket) ou d’un autre ni la possession d’un serveur sql privé. Moi je n’utilise pas les plugins mentionnés (à part quelques essentiels). Je connais d’autres sites qui sont très sobres (squelette ultra simple et peu de plugins) et qui ont des soucis de ralentissement ainsi que de fermetures violentes par OVH.
OVH est devenu nul pour un site sous SPIP sur serveur mutualisé. Beaucoup pense comme moi qu’ils cherchent soit à diminuer le nombre de leurs serveurs mutualisés soit à forcer leur client à passer sur des offres supérieures. Il est fort aisé de voir à quel point leur support technique ainsi que commercial sont hyper lents, incompétents, et menteurs pour répondre à ce genre de problèmes. Très souvent ils ne lisent même pas les tickets ou réponses et recrachent toujours les mêmes textes standards. Ils font clairement de l’obstruction pour résoudre les problèmes.
La différence est apparemment flagrante sur la vitesse dans la partie privée entre OVH et d’autres hébergeurs (infomaniak par exemple).
C’est un changement depuis quelques mois constaté par un certains nombre d’utilisateurs déjà sous SPIP 1.9.x et maintenant encore plus souvent sous SPIP 2.0.9. Je ne recommanderais pas de resté sous SPIP 1.9.x biens sûr Mais juste de changer d’hébergeur si vous tenez à rester sur un serveur mutualisé.
Je ne suis pas sûr que cela provienne de ce plugin…
Je l’utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)…
Une solution ou un début de piste serait grandement apprécié
Cordialement,
Pascal JPM
Je pense pas que ça soit un problème l’hébergement mutu d’OVH, urtout si t’as une sql privée avec connexions illimités… A moins d’avoir vraiment une usine à gaz ou des truc mal codés. Enfin en tout cas j’espère !
Lorsque je coupe le plugin Tickets tout va bien, du coup j’imagine que c’est à cause de lui.
Benjamin
De : Benjamin Farrudja [mailto:farouba@gmail.com]
Envoyé : mardi 3 novembre 2009 04:55
À : SPIP Zone
Objet : [SPIP Zone] Lenteur SPIP 2.0.9 [14428] avec Tickets
Salut,
J’ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez
OVH et c’est pas une réussite… A chaque fois qu’on s’approche de Tickets,
dans cfg par exemple, ça rame à mort, voire ça n’aboutis pas…
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
Le problème d’hébergement mutualisé chez OVH est général et ne dépend pas de ce plugin (ticket) ou d’un autre ni la possession d’un serveur sql privé. Moi je n’utilise pas les plugins mentionnés (à part quelques essentiels). Je connais d’autres sites qui sont très sobres (squelette ultra simple et peu de plugins) et qui ont des soucis de ralentissement ainsi que de fermetures violentes par OVH.
OVH est devenu nul pour un site sous SPIP sur serveur mutualisé. Beaucoup pense comme moi qu’ils cherchent soit à diminuer le nombre de leurs serveurs mutualisés soit à forcer leur client à passer sur des offres supérieures. Il est fort aisé de voir à quel point leur support technique ainsi que commercial sont hyper lents, incompétents, et menteurs pour répondre à ce genre de problèmes. Très souvent ils ne lisent même pas les tickets ou réponses et recrachent toujours les mêmes textes standards. Ils font clairement de l’obstruction pour résoudre les problèmes.
La différence est apparemment flagrante sur la vitesse dans la partie privée entre OVH et d’autres hébergeurs (infomaniak par exemple).
C’est un changement depuis quelques mois constaté par un certains nombre d’utilisateurs déjà sous SPIP 1.9.x et maintenant encore plus souvent sous SPIP 2.0.9. Je ne recommanderais pas de resté sous SPIP 1.9.x biens sûr Mais juste de changer d’hébergeur si vous tenez à rester sur un serveur mutualisé.
Cordialement,
Julien
La config est accessible normalement quand tous les rôles sont accordé au webmaster mais pas de bouton ajouter ticket pour les webmaster. J’ai un debug - état des variables du fond qui s’affiche en bas de la config de ticket dans cfg avec le type d’action = webmaster quand j’utilise cette option.
Quand je sélectionne par statut et clique sur admin c’est fonctionnel mais la config est longue à s’afficher. Dans le debug j’ai type d’action = par_statut.
Quand je clic sur rédacteur les admin peuvent toujours s’en servir mais les rédacteurs non ! La config est longue et le debug est le même.
Même si le problème n’est pas là je pense pour tickets, je ne suis pas persuadé qu’OVH est non SPIPfriendly… J’ai une instalation mutualisé et une simple sur deux 90plan différents et ça marche comme il faut ! J’ai deux sites (un sur chaque) qui tournent relativement fort, peut être que vous avez des plus gros projets… Pour ce qui est du support, il faut savoir s’y prendre s’est clair, mais quand on a compris le truc ça marche et pour le coup ce sont les seuls à avoir une hotline non surtaxé ouverte 24/24 7/7 ! Ils mettent le paquet sur le mutualisé avec la création de nouvelles offres. J’ai pas d’action chez OVH je précise !
Je ne suis pas sûr que cela provienne de ce plugin…
Je l’utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)…
Une solution ou un début de piste serait grandement apprécié
Cordialement,
Pascal JPM
Je pense pas que ça soit un problème l’hébergement mutu d’OVH, urtout si t’as une sql privée avec connexions illimités… A moins d’avoir vraiment une usine à gaz ou des truc mal codés. Enfin en tout cas j’espère !
Lorsque je coupe le plugin Tickets tout va bien, du coup j’imagine que c’est à cause de lui.
Benjamin
De : Benjamin Farrudja [mailto:farouba@gmail.com]
Envoyé : mardi 3 novembre 2009 04:55
À : SPIP Zone
Objet : [SPIP Zone] Lenteur SPIP 2.0.9 [14428] avec Tickets
Salut,
J’ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez
OVH et c’est pas une réussite… A chaque fois qu’on s’approche de Tickets,
dans cfg par exemple, ça rame à mort, voire ça n’aboutis pas…
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
J’ai fait la mise à jour du plugin ticket et saisie, il n’y a plus ce problème de lenteur mais la configuration des autorisations par statut ne marche toujours pas : quand pour écrire tickets je veut mettre visiteurs pour permettre aussi au rédacs et admin d’écrire je n’ai même plus le bouton en tant que webmaster…
En tout cas merci à ceux qui s’en occupent.
benjamin
Le 4 novembre 2009 17:09, Benjamin Farrudja <farouba@gmail.com> a écrit :
Le problème d’hébergement mutualisé chez OVH est général et ne dépend pas de ce plugin (ticket) ou d’un autre ni la possession d’un serveur sql privé. Moi je n’utilise pas les plugins mentionnés (à part quelques essentiels). Je connais d’autres sites qui sont très sobres (squelette ultra simple et peu de plugins) et qui ont des soucis de ralentissement ainsi que de fermetures violentes par OVH.
OVH est devenu nul pour un site sous SPIP sur serveur mutualisé. Beaucoup pense comme moi qu’ils cherchent soit à diminuer le nombre de leurs serveurs mutualisés soit à forcer leur client à passer sur des offres supérieures. Il est fort aisé de voir à quel point leur support technique ainsi que commercial sont hyper lents, incompétents, et menteurs pour répondre à ce genre de problèmes. Très souvent ils ne lisent même pas les tickets ou réponses et recrachent toujours les mêmes textes standards. Ils font clairement de l’obstruction pour résoudre les problèmes.
La différence est apparemment flagrante sur la vitesse dans la partie privée entre OVH et d’autres hébergeurs (infomaniak par exemple).
C’est un changement depuis quelques mois constaté par un certains nombre d’utilisateurs déjà sous SPIP 1.9.x et maintenant encore plus souvent sous SPIP 2.0.9. Je ne recommanderais pas de resté sous SPIP 1.9.x biens sûr Mais juste de changer d’hébergeur si vous tenez à rester sur un serveur mutualisé.
Cordialement,
Julien
La config est accessible normalement quand tous les rôles sont accordé au webmaster mais pas de bouton ajouter ticket pour les webmaster. J’ai un debug - état des variables du fond qui s’affiche en bas de la config de ticket dans cfg avec le type d’action = webmaster quand j’utilise cette option.
Quand je sélectionne par statut et clique sur admin c’est fonctionnel mais la config est longue à s’afficher. Dans le debug j’ai type d’action = par_statut.
Quand je clic sur rédacteur les admin peuvent toujours s’en servir mais les rédacteurs non ! La config est longue et le debug est le même.
Même si le problème n’est pas là je pense pour tickets, je ne suis pas persuadé qu’OVH est non SPIPfriendly… J’ai une instalation mutualisé et une simple sur deux 90plan différents et ça marche comme il faut ! J’ai deux sites (un sur chaque) qui tournent relativement fort, peut être que vous avez des plus gros projets… Pour ce qui est du support, il faut savoir s’y prendre s’est clair, mais quand on a compris le truc ça marche et pour le coup ce sont les seuls à avoir une hotline non surtaxé ouverte 24/24 7/7 ! Ils mettent le paquet sur le mutualisé avec la création de nouvelles offres. J’ai pas d’action chez OVH je précise !
Je ne suis pas sûr que cela provienne de ce plugin…
Je l’utilise dans une config très similaire à la tienne et pour moi, ça rame
CONSTAMMENT (test réalisé de 14h à 15h ce jour sur une [14357]) !!
Soit OVH est devenu nul et pas bon du tout (pour SPIP), soit Hébergé SPIP
2.0.9 (ou 10) sur un serveur mutualisé (même sur le plus gros Mutu + SQL
privé) devient impossible dans un cadre sérieux (pour ne pas dire pro) !!!
Mais je pencherai plutôt pour la deuxième solution, vu que plusieurs 1.9.x y
tournent très bien (même bardés de plugins)…
Une solution ou un début de piste serait grandement apprécié
Cordialement,
Pascal JPM
Je pense pas que ça soit un problème l’hébergement mutu d’OVH, urtout si t’as une sql privée avec connexions illimités… A moins d’avoir vraiment une usine à gaz ou des truc mal codés. Enfin en tout cas j’espère !
Lorsque je coupe le plugin Tickets tout va bien, du coup j’imagine que c’est à cause de lui.
Benjamin
De : Benjamin Farrudja [mailto:farouba@gmail.com]
Envoyé : mardi 3 novembre 2009 04:55
À : SPIP Zone
Objet : [SPIP Zone] Lenteur SPIP 2.0.9 [14428] avec Tickets
Salut,
J’ai voulu remettre en prod le plugin Tickets sur des sites mutualisé chez
OVH et c’est pas une réussite… A chaque fois qu’on s’approche de Tickets,
dans cfg par exemple, ça rame à mort, voire ça n’aboutis pas…
Les plugins en marche :
Autorité
cfg : moteur de configuration
Le Couteau Suisse
Crayons
Google analytics
Mediathèque
Saisies pour formulaires
Sauvegarde automatique
Social tags
SPIP Bonux 2.0
Tickets, système de suivi de bugs
Champs Extras2
Interface pour Champs Extras
Mais juste de changer d’hébergeur si vous tenez à rester sur un serveur mutualisé.