Le document aborde les meilleures pratiques pour optimiser les performances et la disponibilité des applications web, en mettant l'accent sur l'utilisation des versions récentes de logiciels et des techniques telles que le tuning de serveur, la mise en cache et le load balancing. Il propose également des solutions pour gérer une montée en charge, comme l'ajout de serveurs et l'utilisation de bases de données NoSQL. Finalement, il fournit des références pour approfondir ces sujets et améliorer les systèmes.

1. êtes-vous prêts pour le succès ?

2. Huh !? Qui ça ? Steven VAN POECK autodidacte, 12 ans de PHP, entre autres stevenvanpoeck http://joind.in/4352

3. should i stay or should i go* ? * the clash, 1981

4. le début

5. quelques utilisateurs Coût : Apache 2.2.16 + mod PHP 5.3.3 + MySQL 5.1.49 Performance : Disponibilité :

6. Resp time # requests # Concurrent requests Max connexions simultanées : 9 ~4 500 utilisateurs

7. un peu plus d'utilisateurs Coût : Apache 2.2.16 + mod PHP 5.3.3 + MySQL 5.1.49 Performance : Disponibilité :

8. un peu plus d'utilisateurs Apache 2.2.16 + mod PHP 5.3.3 + MySQL 5.1.49 Coût : Performance : Disponibilité :

9. solutions utilisez les dernières versions stables des briques logicielles

10. distribution de charges : séparation serveur web / db

11. côté disponibilité : FastCGI pour PHP

12. côté ressources : nginx

13. tuning serveur Web (Nginx) worker_processes -> 1 par CPU mais plus de 4 est inutile

14. worker_connections -> 2048

15. keepalive_timeout -> entre 10 et 20

16. access_logs off -> réduction I/O (utilisez Google Analytics pour stats)

17. error_log <LOGFILE> error|crit -> réduction I/O (désactivez avec error_log /dev/null crit)

18. solutions (suite) tuning PHP cache op-code PHP (APC, eAccelerator, Zend Server)

19. utilisez la dernière version majeure stable !

20. template caching (ex : Smarty)

21. compilation « maison » sans extensions inutilisées

22. always_populate_raw_post_data = Off (utilisez php://input)

23. max_execution_time -> le plus petit possible

24. memory_limit -> adapté à vos scripts

25. realpath_cache_size -> plus si beaucoup de fichiers

26. realpath_cache_ttl -> le plus élevé possible

27. enlever Suhosin patch

28. un peu plus d'utilisateurs MySQL 5.5.16 Nginx 1.0.8 + FastCGI PHP 5.3.8 Coût : Performance : Disponibilité :

29. # requests Resp time # Concurrent requests Max connexions simultanées : 27 ~13 000 utilisateurs

30. encore plus d'utilisateurs MySQL 5.5.16 Nginx 1.0.8 + FastCGI PHP 5.3.8 Coût : Performance : Disponibilité :

31. encore plus d'utilisateurs Coût : Performance : Disponibilité :

32. solutions ajout de RAM sur le serveur MySQL

33. tuning MySQL utilisez InnoDB (rowlock)

34. connection_timeout -> le plus bas possible

35. skip_name_resolve = 1 -> réduction appels réseau

36. log = /dev/null -> réduction I/O

37. slow_query_log = 1 -> surveillance cache résultats brutes des requêtes solution ad-hoc dans le code

38. extension AdoDb + memcache optimisation du code exit(ORM);

39. traque et élimination des requêtes dans des boucles

40. exemple solution ad-hoc dans le code : public function query($sql) { static $qCache = array(); // Stockage $qSig = md5($sql); // Cle unique pour la requete // On retourne le resultat directement if (array_key_exists($qSig, $qCache)) { return $qCache[$qSig]; } $rs = $this->db->query($sql); // Requete en base $qCache[$qSig] = $rs; // Mise en cache return $rs; // On retourne le resultat }

41. encore plus d'utilisateurs memcache Coût : Performance : Disponibilité :

42. # requests Resp time # Concurrent requests Max connexions simultanées : 45 ~22 000 utilisateurs

43. toujours plus d'utilisateurs Coût : Performance : Disponibilité :

44. toujours plus d'utilisateurs Coût : Performance : Disponibilité :

45. solutions ajout de serveurs frontaux

46. load balancer

47. sharding pour la base de données

48. failover pour les MySQL

49. toujours plus d'utilisateurs sharding Load Balancer Coût : Performance : Disponibilité : failover 1 3 2 1 3 2

50. # requests Resp time # Concurrent requests Max connexions simultanées : 110 ~50 000 utilisateurs

51. le succès est au rendez-vous ! Coût : Performance : Disponibilité : 1 3 2 1 3 2

52. le succès est au rendez-vous ! Coût : Performance : Disponibilité : 1 3 2 1 3 2

53. solutions perfomances & disponibilité HTTP caching (Varnish, Squid, Nginx…)

54. content distribution network (CDN)

55. le succès est au rendez-vous ! CDN HTTP cache Coût : Performance : Disponibilité : 1 3 2 1 3 2

56. # requests Resp time # Concurrent requests Max connexions simultanées : 175 ~85 000 utilisateurs

57. mais encore ?

58. noSQL MongoDb : http://www.mongodb.org/

59. CouchDb : http://couchdb.apache.org/

60. CouchBase : http://www.couchbase.org/

61. ... ze nuage (Amazon, Azure, Eucalyptus, Google apps...)

62. questions ?

63. Références: Dernières versions briques logicielles Debian : http://dotdeb.org

64. PHP : http://www.php.net Tuning PHP / Nginx : http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/

65. http://php.net/manual/en/ini.core.php

66. http://talks.php.net/show/perf_tunning

67. http://phplens.com/lens/adodb/docs-adodb.htm#memcache Load balancing : http://en.wikipedia.org/wiki/Load_balancing_(computing)

68. Optimisation MySQL : http://www.slideshare.net/ligaya/dpc-tutorial

69. Sharding : http://en.wikipedia.org/wiki/Shard_(database_architecture)

70. Failover : http://en.wikipedia.org/wiki/Failover

71. Memcached : http://memcached.org/

72. CDN : http://en.wikipedia.org/wiki/Content_delivery_network

73. HTTP cache : http://en.wikipedia.org/wiki/HTTP_accelerator

74. https://www.varnish-cache.org/

75. http://nginx.net/

76. http://www.squid-cache.org/