| 330 | | |
|---|
| 331 | | Benchmarks are very difficult to do well; creating truly comparable benchmarks is a complex art. Many of the older performance benchmarks that have shown MySQL to be much faster than PostgreSQL have suffered from a number of problem areas: |
|---|
| 332 | | |
|---|
| 333 | | * Configuration: It's not unheard of to see a a tuned MySQL compared to an untuned PostgreSQL instance. As mentioned above, untuned PostgreSQL used to be particularly pessimistic about what resources it had available. A truly fair comparison would match the amount of memory used by each system. |
|---|
| 334 | | |
|---|
| 335 | | * Transaction support: MyISAM benchmarks involve "transactions" that provide none of the ACID guarantees that PostgreSQL offers. This would frequently mean that apples were being compared to oranges. |
|---|
| 336 | | |
|---|
| 337 | | * Transaction grouping: Related to the above, PostgreSQL would sometimes be hindered in naive benchmarks that don't properly group transactions the way a real application would. That can add the overhead of not just one transaction, but perhaps hundreds of thousands, to the cost of doing updates. |
|---|
| 338 | | |
|---|
| 339 | | * Serial versus concurrent behaviour: A number of the behaviors of MyISAM are tuned for having a single user accessing the database. For example, its use of table locks to control access to tables means that under heavy user loads, it will slow dramatically. PostgreSQL degrades more gracefully with large numbers of simultaneous connections. Beware of naive benchmarks that involve a simple stream of database requests across a single connection. |
|---|
| | 330 | Tests de performances |
|---|
| | 331 | |
|---|
| | 332 | // Benchmarks are very difficult to do well; creating truly comparable benchmarks is a complex art. Many of the older |
|---|
| | 333 | // performance benchmarks that have shown MySQL to be much faster than PostgreSQL have suffered from a number of |
|---|
| | 334 | // problem areas: |
|---|
| | 335 | Les tests de performances sont vraiment compliqués à réaliser correctement; créer des tests vraiment comparables est |
|---|
| | 336 | un art complexe. Beaucoup des tests de performances qui ont présenté MySQL comme plus rapide que PostgreSQL ont |
|---|
| | 337 | souffert de nombreuses zones de problèmes : |
|---|
| | 338 | |
|---|
| | 339 | // * Configuration: It's not unheard of to see a a tuned MySQL compared to an untuned PostgreSQL instance. As |
|---|
| | 340 | // mentioned above, untuned PostgreSQL used to be particularly pessimistic about what resources it had available. A |
|---|
| | 341 | // truly fair comparison would match the amount of memory used by each system. |
|---|
| | 342 | * Configuration : il n'est pas impossible de voir un MySQL configuré comparé à une instance de PostgreSQL qui ne |
|---|
| | 343 | l'est pas. Comme indiqué plus haut, un PostgreSQL non configuré a une utilisation particulièrement péssimiste des |
|---|
| | 344 | ressources qu'il a à sa disponnibilité. Une comparaison réellement juste utiliserait la même quantité de |
|---|
| | 345 | mémoire sur les deux systèmes. |
|---|
| | 346 | |
|---|
| | 347 | // * Transaction support: MyISAM benchmarks involve "transactions" that provide none of the ACID guarantees that |
|---|
| | 348 | // PostgreSQL offers. This would frequently mean that apples were being compared to oranges. |
|---|
| | 349 | * Support des transactions : les tests de MyISAM impliquent des "transactions" qui ne fournissent aucune des |
|---|
| | 350 | guaranties ACID que PostgreSQL offre. Cela revient généralement à comparer des pommes à des oranges. |
|---|
| | 351 | |
|---|
| | 352 | // * Transaction grouping: Related to the above, PostgreSQL would sometimes be hindered in naive benchmarks that |
|---|
| | 353 | // don't properly group transactions the way a real application would. That can add the overhead of not just one |
|---|
| | 354 | // transaction, but perhaps hundreds of thousands, to the cost of doing updates. |
|---|
| | 355 | * groupement de transactions : relatif au point précédent, PostgreSQL serait parfois affecté par des tests simplets |
|---|
| | 356 | qui ne groupent pas correctement les transactions comme les applications le feraient. Cela n'ajoutera pas seulement le |
|---|
| | 357 | coût d'une transaction, mais peut-être de centaines de milliers, au coût total de la réalisation des modifications. |
|---|
| | 358 | |
|---|
| | 359 | // * Serial versus concurrent behaviour: A number of the behaviors of MyISAM are tuned for having a single user |
|---|
| | 360 | // accessing the database. For example, its use of table locks to control access to tables means that under heavy user |
|---|
| | 361 | // loads, it will slow dramatically. PostgreSQL degrades more gracefully with large numbers of simultaneous |
|---|
| | 362 | // connections. Beware of naive benchmarks that involve a simple stream of database requests across a single |
|---|
| | 363 | // connection. |
|---|
| | 364 | * Comportements en série ou en parallèle : un certain nombre de comportement de MyISAM sont ajustés pour n'avoir |
|---|
| | 365 | qu'un seul utilisateur accèdant à la base. Par exemple, son utilisation de vérrous de table lors d'accès à |
|---|
| | 366 | celles-ci implique qu'avec de nombreux accès utilisateurs, MyISAM ralentira dramatiquement. Les performances de |
|---|
| | 367 | PostgreSQL se dégradent plus harmonieusement avec de grande quantité de connection simultannées. Méfiez vous des |
|---|
| | 368 | tests qui n'impliquent qu'un simple flot de requêtes sur la base à travers une unique connection. |
|---|
