Bonjour,
Je suis vénère ! Mon site ne fonctionne plus depuis hier après-midi car mon hébergeur OVH m'a tout simplement fermé ma base de données sans aucun avertissement préalable.  
Voici ce qu'ils disent:
"Nous vous informons que l'état opérationel de base de donnée a changé
d'état et est en "CLOSED". Ceci veut dire que votre base a été fermée.
Vous ne pouvez plus effectuer de requêtes sur votre base de données.
 
Le changement d'état est dû aux surcharges que votre base de données
provoquait sur notre serveur mysql4.60gp. Afin de garantir une qualité
de service pour l'ensemble des autres bases hébergées sur ce serveur,
nous avons décidé de désactiver toutes les bases de données
qui provoquaient le ralentissement de ce dernier.
 
La raison de ce changement d'état est le suivant:
Votre base surcharge le serveur :"
 
Et en plus, je ne suis même pas sûr d'avoir réellement dépassé le 25 mo alloués.
 
Je suis vraiment écoeuré de ces pratiques dégueulasses.
Le pire, c'est que, après avoir saboté mon site, ils me demandent dans le même mail de la restaurer en l'optimisant.
Ils pouvaient pas m'le dire avant ces c***!
"Nous pouvez récuperer les informations de votre base de données
via l'opération DUMP dans votre manager. Ensuite, vous pourrez
effacer votre base de données et la récreer toujours depuis le manager.
ATTENTION: effacement de votre base de données signifie que vous
allez PERDRE toutes les données de votre base de données.
AVANT d'effectuer l'effacement de votre base de données,
effectuez le dump de votre base et vérifiez bien que
vous avez recuperé TOUTES les données. "
 
Mais c'est là ou j'ai besoin de vous. Impossible de faire ce que me dit la hot line "y'a qu"à, faut qu'on", ça ne marche pas.
 
J'ai téléchargé une sauvegarde .dump. Ils me conseille de supprimer ensuite la base, puis de la recréée et enfin d'importer le fichier .dump.
Mais la suppression de ma base ne marche pas car elle est soi-disant "pas vide". Or quans je vais dans PHPmyadmin, y'a rien à vider !
 
Impossible de remttre ça d'aplomb, et j'ai maintenant un site ou j'ai passé tant de temps à le faire, à le référencer, qui est inexploitable. Sans compter que j'ai également fait un gadget Vista travaillant sur cette même base qui a été téléchargé près de 20 000 fois et buggué maintenant.
Tout ça, à cause du zèle de OVH. MERCI OVH !!!!!
 
Alors de grace, help-me les amis, help-me !
 
Aussi, si vous connaissez un hébergeur sérieux, dites-le moi ! Merci.
(Cela dit, ils sont sympa, ils ont quand-même attendu que je paie mon abonnement avant de m'emmerder)

Indice: un de tes utilisateurs a téléchargé ton gadget Vista, a essayé de jouer avec, et a fait 3 millions de requêtes par minutes, ce qui a fait tilté le serveur OVH. Solution: mets en place toi même un contrôleur qui n'autorise pas plus d'un certain nombre de requêtes par utilisateur et par seconde...
 
Pour vider ta base une fois que tu l'as sauvegardée, essaye de la vider à la main (drop index, drop table, ...), puis de la détruire (drop database).

Faire un truc téléchargé 20 000 fois, et le gérer sur du mutualisé, forcément, ça va pas l'faire

 
Dans PHPmyAdmin, c'est écrit: Aucune base de données
Dans l'espace Manager d'OVH, j'ai cette erreur quand j'essaie du supprimer la base : Database is not empty
 

Tu sais, je n'suis qu'un amateur mais j'aimerai bien user de votre aide pour remédier à ces lacunes.

PhpMyAdmin n'a rien à supprimer, puisque de toutes façon l'accès à la base est fermée.
 
Tu prends le problème à l'envers: tu essaye de rétablir la base avant de l'avoir optimisée. Elle a toutes les chances de se refermer dès que tu l'auras rétablie.

J'ai supprimé tout ce qui étaient liés à mon gadget Vista mais je ne sais pas comment "optimiser" ma base.

Pour optimiser ta base vérifie que tu as bien mis des index sur les clés primaires/étrangère par exemple et si tu n'as pas trop de requêtes qui font des full scan (tu peux utiliser mysql explain pour voir ça)

ovh c'est d'la merde.
 
mais aussi pense quant même que 20 000 dwl d'un truc qui requête le serveur, en partant du principe que ton widget fait un refresh toutes les 5 minutes, ça donne 20 000 / (5 * 60) = près de 70 requête par seconde.
 
donc si ton widget utilise une vraie requête avec jointures et autres, à lui tout seul, y'a de quoi mettre à genoux un serveur dédié.
 
utilise une table mémoire, que tu recharges une fois de temps en temps, et donc widget ne doit lire que dans cette table, des infos déjà toutes prêtes à l'emploi... sinon évidement tu vas te faire kick+ban+sodo+gravier par ovh en 2 secondes...
 
OVH c'est de la merde molle en barre, mais là faut pas pousser mémé dans les orties non plus

Tu as accès au détails des logs du serveur? il faut commencer par là, pour détecter d'où provient l'anomalie: est-ce que ce jour là tu as eu trop d'utilisateurs? ou est-ce un utilisateur particulier qui a fait tilter la base et à partir de quelle page du site?
 
Dans le premier cas, l'hébergement mutualisé n'est pas approprié, tu peux dans un premier temps optimiser les indexs, mais il te faudra rapidement changer pour un hébergement payant.
 
Dans le second cas, il te faut limiter toi même le nombre de requêtes par utilisateur, comme le fait OVH, pour éviter qu'un utilisateur particulier n'abuse de ton service au détriment des autres.

Merci à tous pour votre aide.
 
Bon, vous avez tous deviné que je suis un amateur en codage, donc voilà ce que j'ai fait, que j'amerai faire et que je n'arrive pas à faire.
 
Dans un premier temps, j'ai supprimé les requetes liées au gadget, de toute façon, baisé pour baisé.
Ensuite, j'ai uploader tout mon site avec mes sources saines au cas ou un hacker se serait éventuellement incrusté et modifié quelques codes (j'dis ça mais j'en sais rien)
Et j'ai récupéré le fichier .dump qui devrait me servir, d'après OVH à refaire ma base.
 
Ce que je voudrais faire, c'est d'abord, essayer de remettre la base sur pied pour voir si c'est mieux maintenant.
J'ai compris qu'il fallait que je change de type d'hébergement (dédié).
Et que je limite (ou j'essaie) le nombre de requêtes par utilisateur.
 
Et ce que je n'arrive pas à faire, c'est la procédure de OVH pour remettre ma base. Après la sauvegarde .dump, il faut que je supprime celle en place. Mais c'est impossible, j'ai une erreur "Database is not empty". C'est vrai que d'après le manager OVH, elle fait 0.106 mo. Mais comment je peux la vider ?
Je veux bien optimiser ma base mais je précise que mon site n'a subi aucune modif (requetes etc..) depuis des mois. Si ça marchait avant... Non ?
 
Et comment l'optimiser si je ne la vois pas ? vous savez, c'est une petite base ...basique ! J'ai utilisé apache etc au début mais y'a longtemps.

Le problème vient de qui alors ? Moi qui ne connait pas assez ou OVH ?
 
Que dois-je pour avoir un site qui fonctionne ? Changez d'hébergeur ?

Ca risque de ne pas être facile. Ecrire un gadget, c'est à la portée de n'importe qui.
 
Faire du tuning et du profiling, c'est une autre histoire. Comme on te l'a dit, il faut éplucher les requêtes, découvrir les bottlenecks, optimiser ta base, utiliser du caching, considérer une dénormalisation, etc. Ca demande de l'expérience.
 
Passer à du dédié sera peut-être nécessaire, mais ça vient certainement après avoir optimisé le bazar.
 
-1 pour OVH si la fermeture a eu lieu sans préavis, même si on peut leur accorder des circonstances atténuantes.
 
Magic Buzz > Pour info, tu as des éléments précis te permettant d'être aussi catégorique à l'encontre d'OVH?

Des éléments précis, oui, mais pas en ce qui concerne l'hébergement de sites web. Mais vu que c'est la même boîte...
 
Mais en gros, depuis novembre 2005 que je suis dans ma nouvelle boîte qui utilise OVH pour sa messagerie :
 
Coupures très régulières de la messagerie en ce 2006 surtout, et une grosse panne au printemps 2007 : plus d'email pendant 3 semaines.
 
Motifs ? Ah ben y'a un admin qui a trouvé marrant de faire une recompile à chaud du kernel de linux avec des sources en version alpha, et ça a tout foutu par terre. Et ensuite ils ont eu toutes les misères du monde à tout réinstaller (ce qui est bien avec OVH, c'est qu'on sait exactement ce qu'ils font, c'est tout marqué sur le site). Mais 3 semaines sans mails, pour une société c'est plutôt gênant. Je dois dire que cette panne tombait bien, mon patron voulais m'obliger à utiliser mon email du boulot plutôt que mon email perso, qui elle, n'a jamais planté plus d'une demi-journée (sauf un coup mais c'est moi qui avait oublié de renouveler mon nom de domaine )
 
Ensuite, quoi d'autres ? Toujours au niveau des mails, à plusieurs reprises, des collisions, genre d'un coup tu reçoit 20 Mo de mails, qui correspondent à tous les messages que t'as reçu les 6 derniers mois que tu recois de nouveau. Sympa pour faire le tri après. Mais aussi d'autres trucs, genre le filtre anti-spam qui décide de tout bloquer pendant 3 jours. Le mieux c'est le coup où tous les serveurs OVH se sont retrouvés en blacklist des filtres de spam, ou encore la fois où il s'écoulait 24 heures systématiquement avant qu'un mail n'arrive ou ne parte de leurs serveurs... Ca avait duré une semaine, ct cool pour travailler par mails...
 
Bref, OVH je trouve que la fiabilité est très mauvaise. J'utilise mon adresse perso, donc je ne peux pas dire si OVH est performant. De ce que j'ai ouie dire, oui, ils sont performants, réactifs et on bénéficie de plein de trucs 'achement biens avec eux.
 
Sauf que moi je préfère un truc moins réactif mais qui n'a pas besoin de réagir à chaque fois qu'un admin décide de toucher un clavier.
 
 
Et le coup de la base fermée, si c'est effectivement sans préavis, ça ne fait pas remonter OVH dans mon estime... D'autant que sous Nux et des outils tels que Apache, PHP et MySQL, ça me ferais bien mal au cul s'il n'y avait pas une gestion de quotas disque/mémoire/cpu permettant de bloquer l'impact d'un site fou sur le serveur, sans pour autant le locker, chose qui aurait dû être faite avant d'en arriver à des mesures pareilles.
Mais ce qui me choque vraiment, c'est que la désactivation de la base est irréversible : il doit la backuper, et en refaire une nouvelle. Donc les effets de bords ne sont absolument pas contrôlables. S'ils gèrent leur parc de la même manière, cela expliquerait bien des choses.

pour la fermeture sans préavis, je peux la comprendre si jamais le trafic sur la base pénalise tous les autres clients qui sont sur le même mutualisé... d'autre part, sur beaucoup d'offres mutualisées, c'est au client à faire les backups de ses bases, ce qui semble normal (d'autant que OVH fournit un espace de sauvegarde de la même taille que celle de l'hébergement).
En tout cas, ça fait plusieurs mois que j'ai un dédié kimsufi chez OVH, un client pro qui a un dédié (assez balèze) chez eux aussi, RAS...

A la différence près que :
1/ Entre arrêter la base, et la triturer pour qu'elle soit inutilisable, il y a une différence. Ici, OVH a fait une action irréversible sur la base*
2/ Comme je disais, même sous Windows NT 3.51 avec SQL Server 6.5 tu peux brider une base de données afin qu'elle ne surcharge pas le serveur... Je suis pas pro linux, mais on ne me fera pas croire qu'un OS multi-utilisateur/multi-tâche/multi-session puisse être plus limité en terme d'isolation des process qu'un pseudo OS qui a 15 ans, et qui n'est guère plus multi-tâche que multi-session, et dont la couche multi-user n'est qu'une surcouche logicielle posée sur un système mono-utilisateur...
 
* : D'ailleurs, d'un point de vue purement légal, je ne suis même pas certain qu'OVH a le droit de faire ce qu'ils ont fait. Ici ils ont accédé à une base de données qui ne leur appartient pas, et l'on modifiée. Devant un juge qui ne connaît pas les contraintes informatique, c'est du pénal et je ne vois pas quelle défense peut prendre OVH.
 
 
-- Edit : Pour info, je crois que c'est chez Multimania*, il me semble avoir une fois fait un bug qui faisait une boucle infinie sur une requête. Vu qu'il s'agissait d'une frame cachée, je ne m'en était pas rendu compte, donc ça tournait en rond tranquillement comme ça. Mon site n'a jamais été coupé, par contre j'ai reçu une tétrachiée de mails d'avertissament de Multimania m'indiquant que mon site bouffait la totalité des ressources qui lui étaient imparties pendant de longue minutes, et qu'au choix il s'agissait d'un bug dans mon site, ou que leur offre gratuite était insuffisante. Jamais mon site n'a été coupé par contre.
 
* : Je sais plus du tout si c'était Multimania ou Brinkster... Peut-être plutôt Brinkster d'ailleurs...

J'ai déjà été coupé ailleurs pour un site trop gourmand pour du mutualisé (site perso avec un trop grand nombre de hits).
Donc ça ne m'étonne pas trop.
Maintenant je suis chez OVH et ça va mieux (j'ai droit à plus de débit, plus de tout et même d'espace et pour moins cher).
Sur une panne de dédié j'ai aussi pu voir qu'ils ont refait la machine assez rapidement.
 
Bon faut dire que maintenant j'en ai moins besoin aussi, j'ai un peu laissé tout ça mourir

MagicBuzz > Merci pour le feedback, c'est noté. Je les ai aussi quittés à cause de la messagerie peu fiable.
 
Si la DB est a été supprimée / endommagée, l'excuse de la surcharge ne tient pas. Entre parquer la DB et la zigouiller, il y a une différence. Et de fait, je ne vois pas ce qui s'oppose à limiter le CPU / les IO consommés par un client en cas de surcharge.
 
soulmanto> "c'est au client à faire les backups de ses bases, ce qui semble normal"
 
Je dirais plutôt le contraire. Tu es moins bien équipé, alors que eux le sont, et peuvent scheduler tes backups de manière intelligente. De toute façon, ils doivent prendre des backups. Inutile de le faire faire en double et de manière moins efficace par le client.

+1 pour le coup des backups.
 
Je dirais même mieux, un hébergeur sérieux se doit de faire du snapshot en temps réel et disposer de systèmes de remise en service automatisé, garantissant un uptime de 100% même en cas de panne critique.
 
Ce sont des solution qui sont extrêment honnéreuses pour une PME, mais quand on dispose d'une forêt de serveurs, c'est une goutte d'eau qu'il est vraiment stupide d'économiser.
 
Y'a énormément de système de sauvegardes maintenant capable de répliquer les modifications sur des serveurs de sauvegarde quasi en temps réel (genre toutes les 5 minutes), et il est extrêment aisé, avec les outils de virtualisation actuels de redémarrer un certain nombre de serveurs sur un serveur de secours à partir des images de backup dans la minute qui suit leur crash.
 
Donc même si un incendie vient ravager un étage de serveurs, pour le client, dans 99% des cas, il ne doit même pas ressentir la moindre perturbation.
 
Alors que toi, avec ton FTP déjà, tu dois descendre la base mysql pendant 1h pour effectuer le dump, avant de bouffer 80% de ton quota de bande passante en dwl du dump.
 
Donc non, le client n'a pas à faire les backups. Tu dois t'assurer d'avoir les sources, ça oui, plus éventuellement un backup de temps en temps, mais principalement pour utilisation personnelle et planifiée. Genre avant de mettre en ligne une V2 d'un site, il est de bonne augure de faire un backup complet de la V1 par ses propres moyens, afin de ne pas avoir à demander à l'hébergeur les backups si la mise à jour foire. Mais pour tous le reste (défaillance métérielle/logicielle, attaque virus/vers/pirate ou autre) c'est totalement à la charge de l'hébergeur, qui sera bien plus efficace que le client.

heu oui, mais là on parle d'un serv mutualisé, donc censé être assez bas de gamme dans les offres d'un hébergeur... on peut pas demander la panoplie complète des services non plus!

ça ne change rien.
 
si demain leur serveur mutualisé crâme et que ça se solde par la perte des 500 sites hébergés dessus, y'a quelques clients qui vont faire de la mauvaise pub... alors que c'est tellement plus simple d'installer un service de snapshots (d'autant que c'est supporté en natif par les FS de Linux)...
 
au contraire, tu auras généralement bien plus de services sur ce genre d'offres que sur un serveur dédié, où les outils ne peuvent pas être mutualisés, donc bien plus honéreux (entre une licence à 500 € pour 500 sites et une licence à 500 € pour un site unique, je crois que j'ai pas besoin de te faire un dessin savoir quel serveur qui sera équipé du logiciel...) et quand il ne s'agit pas d'un problème de coût de licence, il s'agit d'un bête coût en temps humain... 1j de setup pour le serveur de 500 clients ou 1j de setup sur le serveur de chacun des 500 clients... hmmm... je te laisse trouver sur quel serveur la solution sera installée.

MagicBuzz > Tout dépend ce qu'ils ont d'installé sur leurs serveurs.
Entre un serveur dédié à 100 ou 150 euros par mois et un serveur remplis à moitié d'hébergement gratuit et à moitié d'hébergement à 0.49 euros par mois, on peut se demander sur quel serveur ils mettront le meilleur système de duplication.
En dehors de ça, ils ne choisissent pas l'installation des sécurités en faisant un bête calcul du genre "serveur mutualisé = 250 euros par mois, dédié = 75 donc on met rien sur les dédiés". S'ils faisaient comme ça alors pourquoi choisir du dédié si on a pas besoin de la puissance d'un serveur phyisque? Ca peut très bien leur faire perdre 10 fois 75 euros soit plus de 700 euros par mois et là on peut se demander si c'est vraiment le bas de gamme qu'il faut gâter.
 
Enfin bon, de toute manière les boites de ce genre ont surement beaucoup plus réfléchis que nous à ce genre de problème pour limiter les pertes potentielles sans faire flamber inutilement les dépenses réelles.

évidement que le calcul n'est pas aussi simple.
 
mais ce que je veux dire, c'est que gratuit/mutualisé ne veut pas dire "grosse merde immonde".
mise à part un niveau limité de ressources physiques, et une contrôl plus que limité du serveur, la qualité du service d'hébergement n'a aucune raison d'être plus faible.
 
c'est d'ailleurs bien le principe de la mutualisation : on paie chacun un tout petit peu afin de s'offrir tout ensemble ce qu'aucun de nous ne pourrait se payer.
 
par contre, notamment pour ce qui est des sauvegardes, autant sur un serveur dédié, tu peux appeller "bonjour monsieur ovh, je viens de dropper par mégarde une table dans ma base, est-ce que vous pouvez la restaurer ?", t'as de grandes chances qu'un admin accepte de passer le quart d'heure nécessaire pour faire la manip, moyennant paiement du service ou non.
sur un mutualisé, on va même pas te répondre.
 
par contre le jour où l'un des deux serveurs prend feu, je mets ma main au feu que l'ensemble des sites des deux serveurs sont dans l'heure qui suit à nouveau en service, et avec une perte de données très limitée (au maximum quelques heures).
 
et dans ce cas, perdre les clients du mutualisé est bien plus grave que de perdre le dédié (et j'ai déjà vécu le souci avec un hébergeur, lors d'une grosse panne chez cet hébergeur, c'est tous nos serveurs mutualisés qui sont repartis les premiers, ils se sont occupés des dédiés qu'en dernier lieu, simplement parceque quand t'as 3 clients de serveurs dédiés mécontents, tu risques de perdre 3 bons clients, mais les risques de répercution sont faibles... alors que si tu fait 1500 clients mécontents, tu perds au final autant d'argent de toute façon, et t'es certain d'être grillé sur le marché pour les 6 mois à venirs.

Le mutualisé cheap peut se traduire par moins de BP, pas de SLA, moins de volume, moins de features, mais pour le reste, je rejoins entièrement MagicBuzz, il est stupide de rogner.
 
Le coût marginal entre faire les choses à moitié et les faire correctement est faible pour l'hébergeur, et largement compensé en cas de désastre ou de pépin.
 
Combien coûte une pub négative, comme celle-ci?
 
Combien de temps passe-t-on en support alors qu'un self-service bien rodé ne coutera rien?
 
Tout ça ne rentre pas dans des feuilles Excel mais la perte en qualité a aussi un coût, même s'il est caché.

Il me semble qu'il y'a des options pour les sauvegardes,
et aussi qu'on peut choisir du disque sécurisé ou pas, et si on ne prend pas sécurisé on a par ailleurs un espaces de stockage assez grand (3Go dans mon cas, pour du mutualisé à 60€ par an (ou un truc du genre)).
En tout cas là la base n'est pas détruite, mais ils ne veulent pas la remettre en ligne avec les mêmes identifiants c'est ça ?

Depuis ce midi, c'est revenu dans l'ordre. J'ai reçu un mail d'OVH pour me dire que ma base était à nouveau réouverte. Je ne sais pas pourquoi. Peut-être qu'ils ont gentiment fait le bouleau que je n'ai pas su faire ?
 
Mon site est donc à nouveau fonctionnel mais je ne sais toujours pas ce qui m'est arrivé exactement.
 
Ai-je été hacké ? Est-ce les nombreuses requêtes excessives du gadet Vista ? Dans le doute, j'ai coupé les ponts sur ce gadget. Tant pis, tous ceux qui me l'ont téléchargé se retrouvent avec un truc buggué.

Il fait quoi exactement ton gadget ?
 
Si par exemple c'est un "top 5 des derniers articles", tu sais que les 20000 requêtes qui vont arriver à la suite auront le même résultat, du moment que tu n'as pas rajouté d'article.
 
Je te conseille donc de créer une table de cache (si c'est possible, une table mémoire), dans laquelle tu stockes ce que doit afficher le gadget, et tu n'as qu'à modifier son contenu lorsque tu modifies un article. Tu peux même éventuellement travailler avec une variable d'application, qui sera encore plus performante, puisque tu ne fais même plus le moindre accès à la base.
 
Ainsi, même si tu as des millions de personnes qui utilisent le gadget en même temps, la répercution sur la charge globale du serveur sera faible, puisque ces requêtes ne génèreront quasiment aucune charge.

Ce sont des citations qui sont stockées dans ma base.
Mon gadget ouvre avec des iframes une page .php sur laquelle je lance une requête pour aller chercher une citation et son auteur au hasard dans la bdd toutes les minutes.
 
Théoriquement, si je comprends bien, c'est toujours la même requête qui s'effectue autant de fois que mon gadget est installé. A cela il faut ajouter les autres requêtes des autres page .php correspondant aux versions antérieures de mon gadget pour ceux qui ne l'ont pas mis à jour.
 
Et puis, je reste lucide, parmi les 20 000 téléchargements, s' il y en a 1/4 à l'avoir gardé, ça serait déjà beau.
 
Alors, est-ce que ça, ça peut mettre à plat mon serveur mutualisé ? ...

Oui. 1/4, ça fait donc 5000 personnes. Donc faut faire 5000 requêtes par minutes, ou 83 requêtes secondes. Faut arriver à les faire, surtout sur un mutualisé. Donc clairement, la charge est trop importante

OK, je comprends. Ce que je trouve bizarre de la part d'OVH, c'est qu'ils ne m'ont pas alerté avant de fermer ma base. Le nombre de requêtes a du monter progressivement en 8 mois.
 
Bref, je me demandais quel type d' hébergement conviendrait pour ça ? Est-ce qu'un serveur dédié serait un minimum ? Car je regardais les tarifs mais heuuu comment dire... ça douille !

T'en a beaucoup des citations ? Le plus simple, c'est de les recopier dans un tableau en PHP, et piocher dedans aléatoirement. Là les perfs supporteront sans problème cette charge.
 
Evidement, pour maintenir les données, c'est moins pratique.
 
Sinon, comme je disais pour le cas d'un "top 5" d'articles, tu charges toutes tes citations dans une variable d'application, et tu n'as plus qu'à modifier cette variable que lorsque tu modifies les citations dans la base.

Ou alors que la citation sélectionnée au hasard soit la même pour tout le monde. Mais il y'a toujours le problème du nombre de hits pour un hébergement mutualisé.

En attendant de trouver une solution, j'ai remis en service mon gadget mais avec une actualisation tous les 1/4 d'heure.
Ca divisera par 15 le nombre de requêtes. Je pense que ça devrait tenir quand-même.

C'est vrai aussi que toutes les minutes ça servait vraiment à rien. 15 minutes c'est pas plus mal en effet.

Périodicité trop courte et absence de caching, alors que ton appli est clairement candidate à du caching féroce.
 
Je ne sais pas si c'est possible avec Symfony, et si c'est (relativement) aussi transparent qu'en Java (Hibernate/Spring).
 
Au pire, comme le propose MagicBuzz, j'opterais pour une solution "bien crade" genre tout hardcodé, à la limite généré périodiquement sur base de la DB.
 
Crade, moins maintenable, mais tes perfs vont voler dans d'autres sphères à bon marché!