Kioob

Si tu gères le cache navigateur correctement (ETag et/ou date de dernière modification), le gain de ressources sera certainement bien plus important.

Patrick : parce que c'est le cas. L'URL rewriting ne laisse absolument aucune trace coté "client", il n'y a rien du tout qui puisse permettre à qui que ce soit de s'avoir qu'il y a du rewriting. Même si un moteur décidait de pénaliser ou favoriser le rewriting, ce ne serait pas techniquement faisable. Seulement si c'est mal fait qu'il y a des pages en double à différentes URL ou autres joyeusetées de ce genre, là ça peut poser problème : Google doit alors tenter de détecter les pages en double afin de "nettoyer sa base". Typiquement mettre un ID de session en rewriting, ça empêche de Google de facilement voir que c'est un ID, et donc à chaque consultation du site il se retrouve avec des centaines/milliers de nouvelles URL... alors qu'il s'agit des mêmes pages. Bref comme dis plusieurs fois au dessus, ce que Google n'aime pas c'est la mauvaise utilisation du rewriting. EDIT : hem, j'avais loupé plusieurs messages en fait.... donc ça fait un peu doublon

Bonsoir, d'un point de vue conceptuel, "c'est le mal" : redondance de données = prend plus de place = difficulté à maintenir = risque d'erreur. En pratique toutefois c'est parfois judicieux, si ça peut éviter les jointures suivies de "group by" sur du gros volume. C'est surtout une question de volume de données et ratio lectures/écritures. C'est pas mal utilisé pour les forums par exemple. Je ne réserve ce genre d'agrégation de données que pour les grosses tables, sinon c'est s'embêter pour pas grand chose : le moindre update dans ta table principale à cause d'un insert ou delete dans la table secondaire implique aussi un verrou sur cette table principale et la purge du cache de requête ; ce qui n'aurait pas forcément été le cas sans ça. Bref, comme d'hab réponse de normand : "ça dépend".

Finalement tu optes pour un certificat sur clé USB quoi

Bonjour, oui c'est possible et la solution la plus basique à mon avis est de mettre une balise "meta refresh" en tête de page, afin de raffrichir la page automatiquement toutes les 60 secondes par exemple.

Il peut parfois y avoir un "mod_throttle" ou équivalent qui applique des quotas par vhost oui ; mais ce n'est pas toujours le cas et les infos d'un tel module ne sont (à ma connaissance) pas partagées entre les nodes du cluster ce qui empêche toute limitation en temps réel de manière précise par l'hébergeur. Ce qu'on retrouve plus souvent c'est un quota de hits et/ou trafic à la journée, vérifié de manière automatisée une fois par jour. Pour le cas d'OVH je ne sais pas exactement comment ils procèdent, mais de manière générale ce genre de pic n'est pas facile à détecter sur un cluster. Quand tu as un "monstre" qui bouffe 500 millions de hits à la journée, difficile de remarquer le petit million de hits de pic de trafic. Maintenant si le pic de trafic est généralisé sur un assez grand nombre de sites, c'est une autre histoire.

Le gros avantage pour moi est de pouvoir mettre un long temps d'expiration (30 jours par exemple), sans pour autant risquer que les mises à jour mettent un mois à se propager. Donc même avec une seule mise à jour par an, j'achète.

Hello, j'utilise depuis longtemps une technique similaire, et j'aurais plusieurs remarques : - attention à Firebug : en effet depuis Firefox 3 celui ci est buggé et a une facheuse tendance à désactiver le cache (généralement c'est une fois sur deux) - normalement les URL avec paramètres ne doivent pas être mise en cache (cf RFC il me semble), il est donc préférable de passer par un rewriting pour obtenir le même genre d'URL qu'indique KnockedMaster. Chez moi ça donne généralement un truc de ce genre : /include/default.{timestamp}.css L'idéal étant certainement d'utiliser le numéro de version de subversion, mais faute de mieux...

Euh si, complètement.... à moins que le cluster soit déjà blindé à mort, ça encaisse beaucoup mieux qu'un simple dédié. Le seul risque c'est que l'hébergeur coupe le site pour les ressources consommées... si toutefois le pic est suffisamment élevé pour être détecté.

Dadou : si si, chez les "gros" (Sivit, OVH, Reagi, et sûrement d'autres) il s'agit bien d'un cluster mutualisé. Mais chez les petits ou moyen, c'est effectivement rare.

Ce qui est bizarre c'est qu'au taf je suis en 1500, et les postes Linux comme Windows accèdent parfaitement à ton site malgré cela.

Faudrait essayer de voir quel élément du routage coince avec cette taille de paquet, et perso je ne connais que très très vaguement ce domaine. Et surtout je ne peux pas tester, que ce soit chez moi ou au taff, ton site est parfaitement accessible sous Linux (mais pas de Livebox à dispo). Éventuellement s'il s'agit d'un petit hébergeur qui est prêt à prendre des risques, qu'il essaye un truc du genre : iptables -A OUTPUT --sport 80 -p tcp -m tcp --tcp-flags SYN,RST,ACK SYN,ACK -j TCPMSS --set-mss 1428 Après faut voir si c'est à ce niveau que ça "coince", mais perso la seule fois que j'ai rencontré un problème de MTU c'était à cause d'un soft spécifique sur le serveur, et cette modif du paquet via iptables a résolu le soucis. EDIT : je viens de voir que c'était Orange ton hébergeur... un comble quand même que les abonnées Orange ne puissent accéder aux serveurs Orange, alors qu'ils ne sortent jamais du réseau ! En tous cas je ne sais pas si c'est parlant, mais j'ai testé mturoute, et il indique que c'est 193.251.126.81 ( ge-4-3-0-0.noaub101.Aubervilliers.francetelecom.net. ) qui n'accepte pas les MTU supérieurs à 1469.

De ce que j'ai pu voir avec mes clients, c'est que chaque cas est différent : selon l'audience de l'émission, la façon dont le présentateur va parler de ton site, et ton référencement sur les termes que les spectateurs vont retenir, cela peut changer du tout au tout. De l'impact "non visible" à l'impact "cluster saturé pendant 48 heures", il suffit parfois de peu. Félicitations en tous cas

Aucune idée, le mieux c'est de demander je pense.

Jamais essayé. Mais c'est plus à comparer à la solution de Google qu'à OpenX : c'est en outil "en ligne", déjà "hébergé".

Hello, le umask est une sorte de "filtre" qui vient se retrancher (en gros hein) aux droits que tu indiques. Sur beaucoup de systèmes il est à "022" par défaut. Donc quand tu indiques de créer un dossier en 777 c'est converti en 755. Plusieurs solutions pour y remédier : *) avant de faire le mkdir tu modifies l'umask (via la fonction PHP), tu crées ton dossier, puis tu remets l'umask comme il était. En effet le umask est conservé pour toute la durée du processus, et si tu ne le remets pas comme il était tu pourrais avoir des effets de bord dans d'autres scripts. *) juste après ton mkdir() tu fais un chmod(), dans le même script. Généralement on déconseille cette approche car pendant un pouillème de seconde le dossier/fichier est créé avec trop de droit, avant de voir ses droits restreints ; mais dans ton cas tu cherches à faire le contraire, les effets de bords seront donc moins importants. *) ou bien faire avec. Dans ta tambouille je ne sais pas ce qui tourne sous quel utilisateur, mais si le propriétaire du dossier est le "bon", les droits 0755 suffisent amplement.

Hello, dans ce cas précise peut être un peu plus le fond de ta pensée, car pour le moment j'aurais tendance à voir le même genre de solution que Leonick.

Je crois que tout est expliqué sur cette page : il s'agit de la compression "interne" de PNG, qui peut visiblement être faite de différentes façons ; mais dans tous les cas ça m'étonnerait que tu t'amuses à recréer ton propre soft de manipulation d'image uniquement pour modifier la procédure d'enregistrement (qui devient très longue d'ailleurs, optipng prend bien une trentaine de secondes par image).

Dudu : je suppose que c'est expliqué (au moins partiellement) dans les docs des outils tels que optipng. Ce que je reproche généralement à ces outils c'est qu'ils conservent les "metadata", alors que c'est parfois le truc le plus lourd de l'image.

Hello, pour ton trafic, j'aurais tendance à dire qu'un SP bestof est très largement suffisant. Mais il faut relativiser : puisque tu utilises un panel, ton serveur MySQL est très probablement mal configuré (ou du moins utilise la configuration d'origine, c'est à dire moins d'1% de la mémoire disponible sur la machine). Donc à moins que ta base de données ait moins de 8Mo d'index, ça va pas être folichon. Je ne suis pas forcément objectif, mais à mon avis un "SP mini" infogéré tournera mieux qu'un "EG bestof" géré à coup de Plesk ou autre solution du genre. Et ca tombe bien, un SP mini avec l'infogérance de Dan est dans le même ordre de prix que l'EG bestof, les soucis en moins.

La doc officielle d'OpenX, bien qu'en anglais, me semble pourtant assez bien faite non ? Sinon en solution "hébergé" il y a aussi AdsTronic, c'est français et ça évite d'encore dépendre de Google.

Ah oki, je ne te suivais pas. Dans ce cas oui comme le signale jcaron via une carte à puce cela doit probablement être faisable... même si la carte en question reste probablement déplaçable. Dans tous les cas il ne faut pas se leurrer : ce n'est pas pour du grand public, donc peu importe la contrainte matérielle, la société fera avec. Non ? Mais pour le coup le plus simple serait probablement le VPN, ainsi seuls les ordinateurs "physiquement" (hem, wifi tout ça) reliés au réseau de la société auraient accès au site en question.... si c'est bien de ça que nous parlons.

Bah tout comme pour une clé SSH, tu la conserves. Ce n'est pas lié au numéro de série de ton processeur ou autre. Ce n'est ni plus ni moins qu'un "badge de sécurité" version numérique. Tu le conserves sur toi pour tes déplacements si besoin.

A priori : le même que pour une connexion SSH via une clé plutôt qu'un mot de passe. C'est bien beau d'utiliser un "super cryptage" pour la communication, mais si au final l'utilisateur met le prénom de ses enfants, de sa copine ou encore sa date de naissance, ça ne sert plus à grand chose. Dans ce genre de cas utiliser un certificat me semble assez pertinent. Pour moi c'est une identification bien plus "forte" qu'un couple login/mot de passe qui seront notés sur un post-it sur l'écran car trop complexes. Enfin je vois ça comme ça, il y a sûrement d'autres avantages. Pour quoi les impôts (pour la déclaration en ligne) par exemple utilisent cette technique ? Est ce dans un but ergonomique, technique, juridique, autre ?

Hello, les certificats servent justement à cela oui. Créer un certificat différent par machine, à installer dans chaque navigateur.