Introduction

Tout d'abord, un «cronjobs», aussi nommé «Scheduled Task», est une tâche exécutée de façon périodique à tous les intervalles de temps spécifié. Cette simple caractéristique permet d'exploiter une possibilité colossale ! Ainsi, n'oublions pas que l'informatique c'est l'automatisation de l'information (voir Technologie - Informatique - Introduction). Faire les choses automatiquement au bon moment sans intervention humaine, c'est là tout l'avantage nécessaire, afin de dépasser les limites de l'ordinateur.

DOS

Une tâche planifiée en dehors du fait qu'une fenêtre apparait pour prévenir qu'un événement dans un calendrier est arrivé, n'est pas vraiment utile (puisqu'à cette époque, on fermait l'ordinateur lorsqu'on ne l'utilisait pas), ni même exigeant pour une machine ! C'est que le DOS, n'avait pas une vision réseau ou collaboratif. L'idée même de cronjobs n'était exploitable qu'avec des TSR (Programme résident). Il n'y aucune commande permettant d'exploiter ce genre de possibilité dans la version traditionnelle de se système d'exploitation.

Unix et BSD

Les cronjobs sont très bien intégrés et offre une gamme incroyable de possibilités. Toutefois, seuls les cracks de l'informatique exploitent convenablement cette possibilité. La fluidité du traitement est exceptionnelle. La commande exploitant cette possibilité est nommée «crontab».

Linux

Les cronjobs sont aussi bien exploités qu'avec Unix, il y a de plus l'intégration de cette possibilité du bureau de Gnome ou KDE. La commande exploitant cette possibilité est nommée «crontab».

Windows

Encore une fois, l'utilisation de cronjobs n'est pas très flexible, et passe par le «Planificateur de tâche». Cette possibilité n'est pas vraiment exploitée en dehors des applications Office de Microsoft ou de LotusSmart Suite d'IBM.

Web

L'arrivée du Web a complètement changé la façon de voir les choses, car d'une part, l'idée de travailler sur un poste personnel et lorsqu'une tâche est complétée, de la transmettre et de l'installer sur un autre poste est maintenant dépassée. D'autre part, le volume gargantuesque de requête demandé à un serveur, à cause que la demande n'est plus local ou à proximité, mais mondiale, fait que le développement hâtif n'est plus pertinent. Une des premières idées qu'il faut changer, c'est que contrairement à autrefois, il faut effectuer la planification d'une requête ! Ainsi, on ne peut plus calculer et générer immédiatement un résultat.

Par exemple, si votre rapport de la semaine prendre 2 minutes à générer et nécessite un traitement intense de la part du serveur et que vous avez 500 requêtes entre 9h00 et 11h00, il claire, que mathématiquement parlant, vous allez faire flancher le serveur et qu'il ne pourra pas fournir, certains internautes ne recevront pas le résultat, les autres le recevront qu'après 2 minutes. Il sera beaucoup plus judicieux de créer le rapport le dimanche à minuit et de conserver le résultat dans une BD ou un fichier XML et de retourner dans le rapport ce résultat précédemment sauvegardé le dimanche à minuit lorsqu'un internaute le demandera. Ainsi, ils ont auront tous un résultat obtenu en moins de 2 secondes et il n'y aura pas de surcharge du serveur dans une condition normale.

Les sites ayant un trafic énorme exploitent également ce genre de possibilité au niveau de leur page de contenu. Ils généreront des pages HTML de façon périodique, soit une fois par jour, une fois par semaine et ainsi de suite afin que la page dérange le moins possible les services offerts au serveur Web. De façon concrète, le CMS Drupal et l'analyseur de journal d'accès de fichiers Awstats exploitent beaucoup ce genre de possibilité.

Voir également

Articles - Optimisation pour des sites à haut niveau de trafic