1- Maîtriser les techniques de débogage sous Linux (fautes de segmentation, surcharges et insuffisances de mémoire, crashs)
2- Série « Develop rock-solid code in PHP » : 1ère partie
3- Connecter un middleware à Apache 2.0. Cet article présente un exemple de module de filtre Apache 2.0, puis illustre la nouvelle API par un exemple.
4- Utiliser des formulaires HTML avec PHP. La possibilité de manipuler facilement l'information soumise par l'utilisateur à travers un formulaire HTML a toujours été l'une des forces de PHP. En fait, PHP version 4.1 ajoute plusieurs nouvelles façons d'accéder à cette information et d'enlever de manière effective celle utilisée le plus communément dans les versions antérieures. Cet article s'attarde donc sur les différentes manières de traiter l'information soumise par un formulaire, que ce soit avec des versions PHP anciennes ou plus récentes.
5- RunTime: Commutation de contexte, deuxième Partie Cet article s'attarde sur deux comportements du "scheduler". Le premier étant sa réaction à ajouter plus de choix lors de sa décision de commutation. Le second démontrant l'impartialité par la réalisation d'une charge de travail uniforme dans les multi-threads. Le code source est fournit de façon à ce que vous puissiez l'expérimenter vous-même.
6 - Comment accélérer le démarrage de votre application Linux.
Aller plus loin
- Maîtriser les techniques de débogage sous Linux (2 clics)
- Develop rock-solid code in PHP (2 clics)
- Connecter un middleware à Apache 2.0 (2 clics)
- Utiliser des formulaires HTML avec PHP (2 clics)
- RunTime: Commutation de contexte, deuxième Partie (2 clics)
- Accélérez le démarrage de votre application Linux (2 clics)
# Re: Plein d'articles sur DeveloperWorks
Posté par Troy McClure (site web personnel) . Évalué à 1.
SAI MAL
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . Évalué à 1.
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . Évalué à 1.
Néanmoins on y trouve des informations intéressantes :
"Last month's column looked at bare context switch times by using the best primitives on both Windows and Linux. According to those results, context switch time under Windows takes only half as long as under Linux. I concluded that the algorithm for choosing a thread to run is well optimized in Windows."
En gros, linux gère plus mal les threads que Windows NT, d'une part Linux a du mal a supporter plus de 100-150 threads sur un serveur alors que sur ma machine NT de développeur j'atteint couramment 500 threads. D'autres part (et c'est la raison pour laquelle on est limité en nombre de threads) il y a un mauvais support des threads au niveau noyau, qui donne des perfs plus mauvaise que sous NT, et surtout ses perfs se dégradent beaucoup quand le nombre de threads est élévé (ce qui n'est pas le cas sous NT)
C'est la raison pour laquelle RedHat bosse actuellement sur une nouvelle Posix Thread Librairy, quand cette librairie sera stable et que le noyau 2.6 sera sortie (car la librairie a des dépendance au niveau noyau), le support des threads sous Linux pourra rivaliser (voir dépasser) celui de NT.
Je crois que pour RedHat, le mauvais support des threads est un des principaux freins à l'adoption de Linux au niveau serveur, d'ou le fait qu'il investisse beaucoup pour l'améliorer (c'est comme le manque de système de fichiers journalisés autrefois).
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par dinomasque . Évalué à 1.
BeOS le faisait il y a 20 ans !
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par LupusMic (site web personnel, Mastodon) . Évalué à 1.
Le noyau 2.6 effectivement
la complexité de l'algo de gestion des threads serait en 0(1)
Ce n'est pas la complexité, je ne connais malheureusement pas le terme exact. Mais c'est la description du comportement de l'algorythme.
Et pour préciser, le post auquel tu réponds y fait justement allusion :)
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . Évalué à 1.
C'est la complexité du changement de contexte entre deux processus/threads (il n'y a pas de distinction sous Linux).
Plus précisement, je pense qu'il s'agit de la complexité de l'algorithme qui élit le processus auquel serait attribué la prochaine tranche de temps CPU exprimée en fonction du nombre de processus qui la réclament (donc qui sont dans l'état "Running").
[^] # Re: Plein d'articles sur DeveloperWorks
Posté par Anonyme . Évalué à 1.
Bah, justement à l'heure actuelle la RedHat est configurée par défaut avec un maximum de 256 threads/processus.
Bien sûr, il est facile de recompiler soi-même sa Posix Thread librairie avec une limite plus élévée, mais si RedHat à fixé cette valeur par défaut, c'est pour faire prendre conscience au dévéloppeur que pour Linux, 256 threads c'est déjà beaucoup et qu'au delà le système risque de "souffrir".
Par comparaison, quand je lance quelques applis sur mon Duron 900 avec XP (Warcraft 3, Winamp, Opera, et Outlook) le gestionnaire des tâches me donne déja presque 250 threads, au boulot sur ma station de développeur ou j'utilise beaucoup d'applis gourmandes, j'ai déja dépassé les 500.
Imagine, que tu ai acheté un serveur en Rack, et que pour accélérer ton appli serveur, tu souhaites lancer 1000 threads en parallèle. Pour NT c'est une charge de travail raisonnable (surtout pour un serveur), pour Linux c'est délirant, ton système va être poussé dans ses derniers retranchements.
Donc soit tu bride ton appli, soit tu change d'OS (c'est pour éviter celà que REDHAT dépense de l'argent la-dessus).
Le coup du nombre de threads astronomique, c'est justement pour essayer de casser cette image "Linux = limité en nombre de threads".
# Re: Plein d'articles sur DeveloperWorks
Posté par Olivier Jeannet . Évalué à 1.
Le titre est trompeur, en fait cet article regroupe plein de liens pour aider à démarrer sous Linux (qu'est-ce que c'est, comment installer, etc), il ne s'agit pas d'accélérer le démarrage d'une appli Linux.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.