mageekblog - Mot-clé - HTTP - CommentairesLe blog personnel de Frédéric Hardy. Au menu, PHP, agilité, FreeBSD, cuisine et photographies.2021-12-02T08:20:54+01:00Frédéric Hardyurn:md5:26874ca5b8cd4cac8d08b0e68e64f63aDotclearChronique d'un audit technique #2 - raphaelleurn:md5:29d857b3a42bc8e29fcde6eb922af68f2012-10-15T13:40:54+02:002012-10-15T13:55:07+02:00raphaelle<p>Suspens insoutenable. On veut la suite!<br />
en tout cas merci pour ce retour</p>Chronique d'un audit technique #2 - guykurn:md5:b2e9b6dde69d6f180dc90af4c8f709c12012-10-13T09:34:43+02:002012-10-13T09:19:53+02:00guyk<p>Quel suspense. On fait vraiment un métier passionnant.<br />
Merci de raconter des journées pourries comme celles là. Celles qu'on n'ose pas raconter alors qu'elles contiennent en creux tout le ressort de la réflexion.<br />
Je pense à frffvba jevgr pybfr mais no spoil j'attends la suite.</p>Chronique d'un audit technique #2 - yohangurn:md5:9000a239f78a17360162748d7d2f2d962012-10-12T11:53:29+02:002012-10-12T14:31:00+02:00yohang<p>Bientôt une adaptation ciné ?</p>Chronique d'un audit technique #2 - nicourn:md5:caf13051b76f1a0b5c29ddac7c953be22012-10-12T10:49:30+02:002012-10-12T10:37:35+02:00nico<p><img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /> Tout ça pour nous faire vivre le temps passer à la réflexion <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /><br />
ET MOI? JE PENSE A QUOI A PAR A ÇA MAINTENANT<acronym></acronym><br />
Je dors plus, je mange plus, je passe mon temps à réfléchir....</p>
<p>_merci en tout cas pour le retour d'xp_</p>Chronique d'un audit technique #2 - cydelicurn:md5:00e19c891e793bef687d9b58cf54e62c2012-10-12T00:22:04+02:002012-10-12T06:51:15+02:00cydelic<p>le suspense continu, plus d'info que dans le 1er post mais le mystere reste entier. Je sens que finialement ca risque d'être un petit truc de rien du tout.</p>Chronique d'un audit technique #2 - mccricriurn:md5:29a1bd831fa90bbe85e1df8a9e309f042012-10-11T22:21:42+02:002012-10-12T06:51:15+02:00mccricri<p>Ce côté Sherlock Holmes me plait particulièrement dans notre travail au quotidien, mais ce suspens me tue ...</p>Chronique d'un audit technique #2 - Da Scritchurn:md5:43bc608c9e82c2429bcb6c3132c1c2422012-10-11T17:00:10+02:002012-10-11T16:08:07+02:00Da Scritch<p>Il me semble que les appels $.get() et $.post() sont en async par défaut, non ?<br />
Oh... attendez... ne serait-ce pas dû à une structure HTML hyper compliquée (genre tables cascadées) et des requêtes jQuery très peu performantes et mal ciblées qui ralentissent tout le bousin ?<br />
Le tout saupoudrée de procédures de tests bêtement oubliées en prod ?</p>Chronique d'un audit technique #2 - spontexboburn:md5:7bea3f6377a70438fb6295f2e53c8c4c2012-10-11T14:16:22+02:002012-10-11T13:49:58+02:00spontexbob<p>La suite ! La suite ! La suite ! La suite !</p>Chronique d'un audit technique #2 - Alexandre Saloméurn:md5:b111b54c44909713e894213a7a3034ea2012-10-11T14:03:02+02:002012-10-11T13:09:57+02:00Alexandre Salomé<p>C'est un vrai polar que nous avons là ! Comme toi, j'ai cherché après le premier épisode d'où pouvait venir le problème...</p>
<p>Entre 2 épisodes, je me demandais : "mon dieu, mais comment il va faire pour résoudre ça ? va-t'il y arriver ?"</p>
<p>J'ai hâte de lire le dénouement !</p>Client FastCGI en PHP - Cyranourn:md5:339b7c4995836406cc18c6928dba17912012-08-08T09:17:41+02:002012-08-08T08:50:22+02:00Cyrano<p>@mageekguy : en fait mon idée part d'un principe basé sur tes descriptions et en particulier sur l'aspect rapidité. D'autre part, lorsqu'un appel AJAX est effectué, les appels à la base via HTTP par l'application sont déjà terminés, donc le terme de « parallèle » était abusif de ma part. L'appel Ajax étant fait pour récupérer exclusivement des données, le plus souvent au format JSON pour un traitement ultérieur coté client, il y a pas mal de choses coté serveur qui n'ont nullement besoin d'être chargées comme elles le seraient par un appel HTTP. Je me dis donc qu'on doit pouvoir techniquement se simplifier la vie si on fait preuve d'un minimum de bon sens et qu'on ne fait pas abstraction de la sécurité des données.</p>
<p>Je pense enfin qu'il n'y aurait pas davantage de clients attaquant la base de données, les appels seraient simplement exécutés différemment selon le cas pour un résultat plus efficace. Il n'y aurait donc pas plus de goulot d'étranglement que si tout passe par HTTP.</p>Client FastCGI en PHP - tienslebienurn:md5:135e45f0bcf9ad33fde55489eb8c78f52012-08-08T00:37:49+02:002012-08-08T08:50:22+02:00tienslebien<p>Je ne sais pas ce que tu utilises pour créer des liens sur certains mots clés de ton article, mais j'apprécierai que seul la première occurrence d'un mot clé soit transformé en lien afin d'en facilité la lecture.<br />
Ceci dit, l'article est très intéressant.</p>Client FastCGI en PHP - mageekguyurn:md5:59b6cf5740bb7ac00294065cfba9d25d2012-08-07T23:30:59+02:002012-08-07T22:33:19+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2012/08/06/Client-FastCGI-en-PHP#c4199" rel="nofollow">Cyrano</a> : dans ton cas, il faut aussi prendre en compte le fait que c'est la base de données qui deviendra le goulot d'étranglement, vu qu'elle sera attaquée simultanément par plusieurs clients.</p>
<p>Comme d'habitude, pour qu'une optimisation soit réellement efficace, il faut prendre en compte l'intégralité des composants qui permettent d'obtenir le résultat.</p>Client FastCGI en PHP - Cyranourn:md5:4b5fb0cd3c3fd5ce47d14fafd7fac8db2012-08-07T19:14:14+02:002012-08-07T20:47:59+02:00Cyrano<p>Instructif... et inspirant.</p>
<p>Je songe en effet, en marge d'une utilisation pour des tests unitaires, à tout l'intérêt que ça peut présenter pour des requêtes XHR sur des bases ayant des volumes de données importants, et ce en parallèle à l'utilisation via HTTP normale du reste de l'application.</p>
<p>Reste le problème de l'accès à fast-CGI quand on a pas la main sur la configuration du serveur...</p>Client FastCGI en PHP - mageekguyurn:md5:427459706a5f43076a208effe2d925652012-08-07T19:09:36+02:002012-08-07T18:10:59+02:00mageekguy<p>@<a href="http://blog.mageekbox.net/?post/2012/08/06/Client-FastCGI-en-PHP#c4194" rel="nofollow">JeanFrancois</a> : atoum exécute déjà par défaut les tests unitaires en parallèle, mais localement, donc l'idée est de permettre également de le faire en mode distribué.</p>Client FastCGI en PHP - JeanFrancoisurn:md5:00e398297bf05b8c3c322b108bff39c62012-08-07T16:54:49+02:002012-08-07T18:09:28+02:00JeanFrancois<p>Edit de mon précédent message :<br />
désolé, j'avais lu trop vite, et pas vu que tu parlais de gearman. Les arguments que tu avance sont clairs <img src="/themes/default/smilies/smile.png" alt=":-)" class="smiley" /></p>Client FastCGI en PHP - JeanFrancoisurn:md5:a86befac3a977bdc4d3caf2e324f4d052012-08-07T16:52:43+02:002012-08-07T18:09:28+02:00JeanFrancois<p>Très bon article !</p>
<p>Ceci dit, pourquoi dans ton cas (tests unitaires, qui ne nécessitent donc pas de client HTTP a priori) ne pas directement forker ton script (si c'est pour paralléliser), ou utiliser gearman (si c'est distribuer sur plusieurs machines) ?</p>Test du serveur http intégré à PHP 5.4 - arnolemurn:md5:688ea18414b4ac794e43de74b60013b42012-03-12T14:31:18+01:002012-03-12T22:13:31+01:00arnolem<p>Pour ma part, je ne pense pas que ce serveur intégré permette réellement d'être utilisé en tant que serveur de développement tout simplement parce qu'il ne sera jamais utilisé en production. Si le serveur de production est du Linux/Apache, les développements ne doivent pas être fait sous Windows/PHP5.4-server.<br />
A la limite, il peut être utile pour lancer un test ou un petit script pour ceux qui n'aime pas utiliser PHP en CLI.</p>Test du serveur http intégré à PHP 5.4 - Matthieuurn:md5:1b5d9f7511b8e04d853a7a5ffc927b7f2011-07-10T22:40:30+02:002011-07-10T22:35:27+02:00Matthieu<p>En local, j'ai l'habitude d'installer un LAMP/WAMP/MAMP. Je vais donc préférer cette solution tout en un, plutôt que de m'embeter à télécharger et installer PHP + MySql + PhpMyAdmin manuellement. Bref, ça ne me semble pas utile.</p>
<p>De plus, l'idée d'avoir un serveur intégrée au langage PHP, ça me semble aussi logique que d'avoir un serveur MySql d'intégré à PHP... C'est à dire, pas très pertinent. À la limite, proposer une version PHP au téléchargement qui intègre directement un serveur HTTP (apache ou autre), automatiquement configuré pour du dev. Une sorte de PHP-dev quoi. Tiens, ça ressemble un peu à WAMP tout ça... Bref, on tourne en boucle. Et perdre du temps à redévelopper un nouveau serveur HTTP... Ils auraient mieux fait d'en utiliser un existant.</p>
<p>L'article et le test étaient en tout cas très intéressants.</p>Test du serveur http intégré à PHP 5.4 - Nicolas Laforêturn:md5:6732fb7bdb266363efd565ec334c4ae22011-07-08T10:20:08+02:002011-07-08T10:17:08+02:00Nicolas Laforêt<p>Ok, c'est vrai que ce serveur est encore en stade alpha, mais ces perspectives d'évolutions sont intéressantes.</p>
<p>Dommage qu'il n'y ai rien de prévu autour de PHP 5.4 pour le PHP Tour de Lille.</p>Test du serveur http intégré à PHP 5.4 - Olivier Lavialeurn:md5:4f13da555ce6c5007323f11eaf968e8c2011-07-06T22:08:37+02:002011-07-06T21:51:32+02:00Olivier Laviale<p>J'aime bien ta conclusion <img src="/themes/default/smilies/smile.png" alt=":)" class="smiley" /> Pour en revenir à "l'utilisation négligeable des ressources" je parlais bien sûr d'une utilisation en local. Je ne sais pas ce que cela représente sur le serveur de Nintendo. De toute façon, je reste fidèle à Apache, comme ça je peux jouer avec Ruby en même temps <img src="/themes/default/smilies/wink.png" alt=";)" class="smiley" /></p>