C’est quoi les CPU typiques sur les hébergements mutualisés ?

[hibou57]

Bonsoir,

Je me suis toujours dit « les hébergement mutualisé, c’est la cinquième roue arrière ». Et les raisons que j’avais de le penser, et que parfois il arrive que le serveur ne réponde plus pendant une heure dans la journée (pas toujours, heureusement, ça arrive 2 à 3 fois par mois).

Mais là, je tombe des nues (si je peux dire) : pour une certaine exécution que j’ai testé plusieurs fois avec Apache sous Windows avec un dual-core à 1GHz, je comptais 5 secondes. Je me disais « houlala, ça va être l’horreur si j’appelle un tel truc sur le site ». Mais je teste quand-même, et là surprise, il s’exécute, sur le vrai serveur, un mutualisé... en 3 dizième de secondes ! 0.3s contre 5.0s ! 17 fois plus vite. Comment est-ce possible ?

J’ai un peu de mal à y croire, mais pourtant, ça ne fait pas de la magie, c’est bien ce qu’il se passe.

Alors je pose cette question : quels sont les modèles de processeur typiques sur les hébergements mutualisés ? J’ai toujours cru que c’était un genre de i486, parce que c’est ce que renvoyait les informations de configuration de Debian pour ce serveur, et ça me paraissait crédible (pour un p’tit mutualisé).

[Zecat]

Elle fait quoi ta méga fonction gourmande ? Ca serait pas une simple histoire de cahe mémoire sur le serveur ...

Je me souviens que a l'époque ou je bossais sur des grosses bases de donénes en client serveur on arrivait a des perf assez surprenantes avec des gros paquets de données bien choisies en cache (et donc accès à la vitesse de la mémoire et pas ... du disque).

[hibou57]

Elle fait quoi ta méga fonction gourmande ?

C’est pas un méga fonction, c’est juste un truc qui cherche des choses

J’arrête de déconner : c’est juste un programme de statistiques, et il mouline surtout pour chercher des relations entre des éléments.

Ca serait pas une simple histoire de cahe mémoire sur le serveur ...

Je ne pense pas, parce que la mémoire consomée est faible en fait : entre 5 et 10M, plus et c’est surtout le CPU qui est sollicité. Je ne pense pas que mon Windows XP fasse du swap sur 5M de mémoire allouée.

Je me souviens que a l'époque ou je bossais sur des grosses bases de donénes en client serveur on arrivait a des perf assez surprenantes avec des gros paquets de données bien choisies en cache (et donc accès à la vitesse de la mémoire et pas ... du disque).

... cache... cache... est-ce que ça ne pourrait pas être aussi le cache du CPU justement ? Si les données sont éparpillées dans la mémoire, ce qui est le cas, le cache du CPU peut faire sentir son importance.

Peut-être que c’est ça, peut-être qu’ils ont des processeurs avec de très bons cache ou des mémoire à accès rapide ou en tous cas plus rapide que la mienne.

[Rod la Kox]

Je me suis toujours dit « les hébergement mutualisé, c’est la cinquième roue arrière ».

... et combien de sites sont sur mutu ?
80% du web ?

Sacré grosse roue pour une 5e...

[Duffy]

Je crois avoir lu un topic sur le forum d'ovh disant que les mutus étaient héberger sur des clusters de serveurs HG

[hibou57]

Je crois avoir lu un topic sur le forum d'ovh disant que les mutus étaient héberger sur des clusters de serveurs HG

Please, c’est quoi HG ?

[Duffy]

C'est des serveurs avec des processeurs du genre : Intel Bi Xeon E5530 (tout les HG ont au minimum un Bi Xeon) et avec des tonnes de RAM en fonction des besoins (car il y a des clusters pour les serveurs SQL et d'autres pour les Apaches etc ...)

Sinon une offre AWS d'amazon ne serait pas mieux ? Genre quand tu as besoin de générer tes stats tu utilises leur API pour augmenter la puissance CPU et de RAM ?

[hibou57]

C'est des serveurs avec des processeurs du genre : Intel Bi Xeon E5530 (tout les HG ont au minimum un Bi Xeon) et avec des tonnes de RAM en fonction des besoins (car il y a des clusters pour les serveurs SQL et d'autres pour les Apaches etc ...)

Sinon une offre AWS d'amazon ne serait pas mieux ? Genre quand tu as besoin de générer tes stats tu utilises leur API pour augmenter la puissance CPU et de RAM ?

Je ne passe pas mes journées à « faire des stats », donc ça va. Et puis pour ça, une application en locale peut le faire. les avoir directement depuis le site, c’est pour la côté pratique.

Disons que ça a été l’occasion de faire une constatation surprenante, qui m’a eveillé des questions, voilà.

[hibou57]

[...] pour une certaine exécution que j’ai testé plusieurs fois avec Apache sous Windows avec un dual-core à 1GHz, je comptais 5 secondes. Je me disais « houlala, ça va être l’horreur si j’appelle un tel truc sur le site ». Mais je teste quand-même, et là surprise, il s’exécute, sur le vrai serveur, un mutualisé... en 3 dizième de secondes ! 0.3s contre 5.0s ! 17 fois plus vite. Comment est-ce possible ? [...]

J’ai trouvé, et là j’ai vraiment l’air bête : en fait, j’avais oublié que quand je compile pour Windows, la compilation se fait avec les options RuntimCheck activées, et elles ne le sont pas quand je compile pour Debian. Ce n’est pas par accident, je l’avais fait exprêt, pour avoir toutes les chances de détecter des erreurs quand je teste en local. Mais je l’avais complétement oublié...

... et avec les RuntimeCheck (teste de débordement numérique, teste d’indice en dehors des limite, etc), le temps d’exécution peut facilement être multiplié par 10 ou 15. Quand je compile sans cette option sous Windows, je retrouve des temps similaires à ceux que j’ai sur le serveur, et même plutôt 20% plus rapides sous Windows.

Donc voilà, non, ils n’ont pas des processeurs à 15GHz sur le serveur.... l’explication était plus bête que ça


Bon, et zut, je peux pas marquer résolu encore, faut attendre que le Seigneur du Château des Oliviers rentre de vacance gorgé de soleil.