Nous utilisons vmware-server (le truc basique qui fonctionne parfaitement bien) et KVM (le truc en version post-béta qui a encore plein de bugs mais qui marche du tonnerre).
Je pense que Windows gère mal son cache et ses accès disque. Une simple compression avec 7-Zip d'un gros fichier est plus rapide sur vmware+Windows que sur Windows.
Mais le top c'est avec les applications codées avec les pieds (la majorité donc). Qui font des accès aux fichiers par petits bouts. Nous avons par exemple une application codée en... j'ai honte pour le programmeur... en Clarion (bon, lui il en est fier). Il fait l'équivalent d'un sync à chaque écriture dans un fichier. Lorsqu'un ordinateur client fait un recalcul de statistiques par exemple, il y a des millions de syncs. Sur un Windows bare-métal ça prend des plombes: les disques sont en activité permanente. Le pilote vmware pour les disques n'honore pas les syncs. Donc le Linux sous-jacent récupère tranquillou les écritures, les stocke dans le cache, et une fois toutes les 4 secondes tu as la loupiotte des disques qui s'allume brièvement.
Windows: 1h30
vmware+Windows: 3 minutes
Ce n'est pas "de la faute" de Windows, certes. Mais dans ce cas précis, nous avons 30 fois plus de performance (trente !).
Samba par défaut n'honore pas non plus les syncs. C'est écrit dans la doc du genre "les dév Windows sont des brêles, Samba n'honore pas les syncs car ils ne servent à rien dans 99,9% des cas".
En fait il est indiqué "Many Windows applications (including the Windows 98 explorer shell) seem to confuse flushing buffer contents to disk with doing a sync to disk."
Si on a des disques avec pas mal de cache, on ne voit pas ce problème. Ca coûte juste nettement plus cher (SAS haut de gamme au lieu de SATA ordinaire).
Pour nos serveurs SQL c'est pire: la mémoire du Linux sous-jacent a 12 Go de libre, utilisé pour le cache-disque. L'ensemble des bases utiles de notre plus gros logiciel fait environ 30 Go. En utilisation quotidienne, la totalité des données utile se trouve dans le cache Linux. Cela fait qu'on utilise les disques quasi-uniquement en écriture. Ca aide :-)
Si on met ces 12 Go dans le Windows, hé bien le disque s'affole. Je pense que Windows ne sait pas gérer un cache-disque.
Résultat: deux disques SATA ordinaires (RAID 1 logiciel) supportent 180 utilisateurs TSE + un serveur SQL avec 30 Go de données. En Windows bare-métal avec des SAS 15.000 tours + carte RAID on ne passe que 60 utilisateurs avant qu'ils nous insultent au téléphone. Et il faut deux serveurs car TSE+SQL sur la même machine, même pas la peine d'y penser.
[^] # Re: plus vite ?
Posté par Kerro . En réponse au journal Pour utiliser Windows, utilisez Linux. Évalué à 10.
Je pense que Windows gère mal son cache et ses accès disque. Une simple compression avec 7-Zip d'un gros fichier est plus rapide sur vmware+Windows que sur Windows.
Mais le top c'est avec les applications codées avec les pieds (la majorité donc). Qui font des accès aux fichiers par petits bouts. Nous avons par exemple une application codée en... j'ai honte pour le programmeur... en Clarion (bon, lui il en est fier). Il fait l'équivalent d'un sync à chaque écriture dans un fichier. Lorsqu'un ordinateur client fait un recalcul de statistiques par exemple, il y a des millions de syncs. Sur un Windows bare-métal ça prend des plombes: les disques sont en activité permanente. Le pilote vmware pour les disques n'honore pas les syncs. Donc le Linux sous-jacent récupère tranquillou les écritures, les stocke dans le cache, et une fois toutes les 4 secondes tu as la loupiotte des disques qui s'allume brièvement.
Windows: 1h30
vmware+Windows: 3 minutes
Ce n'est pas "de la faute" de Windows, certes. Mais dans ce cas précis, nous avons 30 fois plus de performance (trente !).
Samba par défaut n'honore pas non plus les syncs. C'est écrit dans la doc du genre "les dév Windows sont des brêles, Samba n'honore pas les syncs car ils ne servent à rien dans 99,9% des cas".
En fait il est indiqué "Many Windows applications (including the Windows 98 explorer shell) seem to confuse flushing buffer contents to disk with doing a sync to disk."
Si on a des disques avec pas mal de cache, on ne voit pas ce problème. Ca coûte juste nettement plus cher (SAS haut de gamme au lieu de SATA ordinaire).
Pour nos serveurs SQL c'est pire: la mémoire du Linux sous-jacent a 12 Go de libre, utilisé pour le cache-disque. L'ensemble des bases utiles de notre plus gros logiciel fait environ 30 Go. En utilisation quotidienne, la totalité des données utile se trouve dans le cache Linux. Cela fait qu'on utilise les disques quasi-uniquement en écriture. Ca aide :-)
Si on met ces 12 Go dans le Windows, hé bien le disque s'affole. Je pense que Windows ne sait pas gérer un cache-disque.
Résultat: deux disques SATA ordinaires (RAID 1 logiciel) supportent 180 utilisateurs TSE + un serveur SQL avec 30 Go de données. En Windows bare-métal avec des SAS 15.000 tours + carte RAID on ne passe que 60 utilisateurs avant qu'ils nous insultent au téléphone. Et il faut deux serveurs car TSE+SQL sur la même machine, même pas la peine d'y penser.