Url rewriting et vitesse des requètes

[brakstar]

Bonjours à tous mes amis webmasters, admins, coders, geeks et peut etre même tout à la fois !

Je voudrai savoir si un script de réecriture avec des érreurs ( pas le htaccess mais la source php qui définit et déclare les variables ) peut FAIRE RALENTIR LE SERVEUR PRO SUR LEQUELLE JE SUIS HEBERGE.

Mon hebergeur ma dit qu'il y avait des ports fermés temporairements pour cause de vers luisants se baladant et infectant les serveurs et autres stations connectées.

Pourquoi mon forum est il aussi lent ?

 

[cybervince]

Je ne sais pas si c'est l'alcool, mais j'ai du mal à comprendre.
Tu fais de l'url_rewriting sans .htaccess ? Directement en php ?

 

[siddhy]

Oui c'est possible :
http://developpeur.journaldunet.com/tut ... ting.shtml

 

[brakstar]

J'utilise un htaccess et des sources php modifiés ( ou reprogrammés pour les puristes )

et je trouve que mon forum est lent, je ssais que le rewriting bouffe le serveur mais bon ......

*******

Mais il est lent .......... depuis le rewriting ......

Auriez vous des réponsses ? par raport à la vitesse d'éxécution des requetes et du rewriting ?

 

[Vell]

Salut,

Faisons les choses dans l'ordre :

- Faire le bon diagnostic
- Isoler le problème
- Trouver la solution
- Appliquer la solution

Tu en es encore à faire le diagnostic. Réessayes en passant tes urls comme avant, au moins pour quelques pages, et test.

Sinon, il y'a trop de choix possibles au niveau ralentissement, surtout si tu es sur un dédié.

Tiens nous au courant ! :wink:

 

[nodom]

votre solution consiste à ce que le .htaccess fait appel un script php qui lui contient des règles de réecriture. c'est dangeureux.. le serveur apache risque de se perdre, tomber dans des boucles infinies (ou plus tôt une récursivité infinie)ou monopolliser 70% de la CPU. je suis passé par là et mon hébergeur a rallé, oui c'est très lent. en tout ca si on ouvre cette porte dans un hébergment mutualisé rassurez vous le serveur ne fonctionnera plus. :wink:

 

[brakstar]

Dans le tutorial officel de rewriting apache ( en anglais ) ils ont bien dit de faire attention au boucles infinies mais que des serveurs possédaient des protections contre ce genre d'érreurs de l'utilisateur. Le mien sur lequel est hébergé mon site en a un à coup sur.

En fait parlons de diagnostique comme vous me l'avez recomandé.

Parfois il ne rame pas, parfois il rame.

A mon avis si le rewriting est mal écrit ou il y a une érreure dans le source php, la boucle infinie sera déclenché à chaque utilisateur surfant sur le forum et déclanchant automatiquement l'érreur.

Le matin et le soir tout va très bien disons que le ralentissement commence de 12h00 à 23h00 ( la ou il y a le plus de trafic )

Mais pour ma part je commence à me poser des questions si c'est vraiment moi qui est mal configuré le rewriting. Par exemeple ce matin quand je me suis levé j'avais 2 membres ( dont moi ) et 3 invités ( vers 08h30 ) et la aucun ralentissement .... je reteste maintenant ( 10 h 56 ) et .... aucun ralentissement .

Une question se pose, sur un serveur puissant en suposant ( ce qui peut etre probable ) que j'ai fait une erreure de config dans sources liées au rewriting, que la saturation du serveur soit liés au nombre de visiteurs déclenchant cette boucle maudite. Pourtant j'ai suivi à la lettre différents tutoriaux que j'ai combiner pour obtenir le résultat escompté. Pour mon forum je voudrai aller encore plus loin dans le rewriting mais avant je dois m'assurer que ce probleme ne viens pas de moi ou s'il venait de moi le corriger et surtout comprendre ....

si cela peut vous aider voila comme j'ai rewrité mon forum smf 1.1 béta 3 public

Voici le tutorial pour VRAIMENT réécrire les urls D'un forum SMF 1.1 Béta 3 Publique !

avoir de urls sous forme :

http://www.serveur.com/forum/board-11.0

( niveau du tutos : moyen quand vous avez la solution ! et vous l'avez ! )

Donc suposons que vous avez un forum smf ayant cette url :

http://www.serveur.com/forum/

Premiere chose :

Remplacer la derniere fonction de http://www.serveur.com/forum/source/QueryString.php qui se présente sous forme :

// Rewrite URLs to include the session ID.
function ob_sessrewrite($buffer)
{
	global $scripturl, $modSettings, $user_info, $context;

	// If $scripturl is set to nothing, or the SID is not defined (SSI?) just quit.
	if ($scripturl == '' || !defined('SID'))
		return $buffer;

	// Do nothing if the session is cookied, or they are a crawler - guests are caught by redirectexit().  This doesn't work below PHP 4.3.0, because it makes the output buffer bigger.
	if (empty($_COOKIE) && SID != '' && (!$user_info['is_guest'] || (strpos($_SERVER['HTTP_USER_AGENT'], 'Mozilla') !== false || strpos($_SERVER['HTTP_USER_AGENT'], 'Opera') !== false)) && @version_compare(PHP_VERSION, '4.3.0') != -1)
		$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '(?!\?' . preg_quote(SID, '/') . ')(\?)?/', '"' . $scripturl . '?' . SID . ';', $buffer);

	// This should work even in 4.2.x, just not CGI.
	if (!empty($modSettings['queryless_urls']) && (!$context['server']['is_cgi'] || @ini_get('cgi.fix_pathinfo') == 1) && $context['server']['is_apache'])
	{
		// Let's do something special for session ids!
		if (defined('SID') && SID != '')
			$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?(?:' . SID . ';)((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html?' . SID . '\$2\"'", $buffer);
		else
			$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?((?:board|topic)=[^#"]+?)(#[^"]*?)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html\$2\"'", $buffer);
	}

	// Return the changed buffer.
	return $buffer;
}

par :

// Rewrite URLs to include the session ID.
function ob_sessrewrite($buffer)
{
	global $scripturl, $modSettings, $user_info, $context;

	// If $scripturl is set to nothing, or the SID is not defined (SSI?) just quit.
	if ($scripturl == '' || !defined('SID'))
		return $buffer;

	// Do nothing if the session is cookied, or they are a crawler - guests are caught by redirectexit().  This doesn't work below PHP 4.3.0, because it makes the output buffer bigger.
	if (empty($_COOKIE) && SID != '' && (!$user_info['is_guest'] || (strpos($_SERVER['HTTP_USER_AGENT'], 'Mozilla') !== false || strpos($_SERVER['HTTP_USER_AGENT'], 'Opera') !== false)))
		$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '(?!\?' . preg_quote(SID, '/') . ')(\?)?/', '"' . $scripturl . '?' . SID . '&', $buffer);
	// You can't do both, because session_start() won't catch the session if you do.  But this should work even in 4.2.x, just not CGI.
	else
		$buffer = preg_replace('/"' . preg_quote($scripturl, '/') . '\?((?:board|topic)=[^#"]+)(#[^"]*)?"/e', "'\"' . \$scripturl . '/' . strtr('\$1', '&;=', '//,') . '.html\$2\"'", $buffer);

	// Return the changed buffer.
	return $buffer;

ensuite ajouter cette ligne à http://www.serveur.com/forum/index.php :

$scripturl2 = '/';

juste après :

// Get everything started up...
define('SMF', 1);
@set_magic_quotes_runtime(0);
error_reporting(E_ALL);
$time_start = microtime();

Ligne 37 environ

ensuite :

Editez ces 3 fichiers :

Sources/BoardIndex.php
Sources/Display.php
Sources/MessageIndex.php

Remplacer les expressions contenant :

'<a href="' . $scripturl . '?topic=' .

par :

'<a href="' . $scripturl . '/forum/topic-' .

puis toujours dans ces fichiers

'<a href="' . $scripturl . '?board=' .

par :

'<a href="' . $scripturl . '/forum/board-' .

Ensuite rechercher dans vos fichiers ****.template.php et vos 3 fichiers sources précédement modifiés les codes contenant :

?board=

remplacer les par :

/forum/board-

idem pour les codes contenant :

?topic=

changer par :

/forum/topic-

ensuite il faudra déclarer la variable globale dans vos fichiers ****.template.php comme ceci

global $scripturl2,

déclarer partout ou cela est néccéssaire.

déclaré la aussi dans display.php ces lignes sont en générale en haut de page mais méfiez vous.

puis configurez votre .htaccess placé dans votre repertoir : /forum/ de cette façon ( ceci peut varier selon les différents serveurs moi c'est papache ) :

RewriteEngine On
RewriteRule ^topic-([^/]+)[/]?$ /forum/index.php?topic=$1
RewriteRule ^board-([^/]+)[/]?$ /forum/index.php?board=$1

et voila mes amis vos urls seront sous forme de :

http://www.serveur.com/forum/board-11.0

et vos topics :

http://www.serveur.com/forum/topic-72.0

 

[nodom]

désolé mais je ne peux pas regarder dans le détail globalement ça semble bon à mon avis pas de risque de boucle infinie, essayez de faire un débogage, en créant un journal qui inscrit dans un premiers temps tous les urls visités, et dans un deuxième temps le processus de rewriting. avant ça commencer par voir le log du serveur. après essayer de voir comment la mémoire est alloué par le script. sinon essayer (c'est important) de voir pour une url, que fait exactement php avant d'arriver à l'url finale.

 

[brakstar]

ok je vais faire tout ça, il va falloir que je vois avec l'hébergeur pour avoir les logs, je ferai ça en periode creuse vers 3 du matin car avec le trafic qu'il y a, le loggeur va me sortir 10 000 pages pour 5 min d'action du site.
Merci en tout cas, je vais aussi demander à l'hebergeur si la restrication de certains ports en ce moment peut influer sur la vitesse des requètes

because of a Worm virus spreading through the internet we are forced to temporarily close certain TCP ports on the Virtual Servers. Ports are: 445 8888 7778 8594 8563 and 7778. If necessary they remain closed until 30-09.

 

[nodom]

sinon essayer (c'est important) de voir pour une url, que fait exactement php avant d'arriver à l'url finale.

surtout faites votre propre log pour ça, voir comment réllement le script construit l'url final, vous pouvez même mesurer le temps en affichant l'heure de début et de fin il est possible de découvrir des surprises pour cerains urls.

 

[brakstar]

OK pas de probleme. Merci de vos conseils.
J'en profiterai pour vérifier mes autres scripts php tournant sur le site.
Peut être aurai je des réponsses ..... J'utilise déja des logs mais c'est pour la sécurisation de ma station de travail. Ca sera plus qu'intérrésant d'avoir un logueur par contre à mon avis bonjours l' espace de la base my sql qui enregistrera les logs si le logueur fait une description complete de tout ce qui bouge j'éssairai de le configurer pour qu'il ne prenne en compte que les requetes d'un seul ip ( le mien ) ça évitera les logs parasites.

Le geek enchaine les problemes tous les jours dans l'ombre pour créér de la lumière et pédale tous les jours pour que la luminosité crée reste intacte.

merci à vous nodom

 

[nodom]

c'est pas suffisant mysql. insérer des ligne de log entre les lignes du script de rewriting

 

[Vell]

Je comprends mieux, j'avais cru qu'il s'agissait d'un .htaccess généré dynamiquement. (ce qui est tiré par les cheveux )

Mais là c'est plus simple, pour diagnostiquer plus facilement tu prends un script qui calcule le temps de génération de la page, pour la page totale, puis ensuite petit bout par petit bout, dans tes pages.

A un moment tu vas finir par tomber sur le morceau qui prend du temps à s'executer, et tu pourras ensuite passer a la finalisation du diagnostic : pourquoi est-ce que c'est partie est lente ?

 

[brakstar]

Un grand merci à toi [Nodom]

Jai vu le log de mon forum et il y a plus de 40 erreurs rien que sur la page d'index !

Pourquoi ? Parceque je suis vraiment un nul ! J'ai oublié de déclarer la variable $scripturl2 dans global à certain endroit et à certaines pages. maintenant mon forom BOOST A MORT. Il est toujours en maintenance mais c'est presque finit. Un grand merci à l'équipe smf qui à conçu dans la partie admin un loggeur d'erreur qui me dit quand meme pas le numéro de ligne mais la page ou ça coince.

Créer la variable mais oublier dans la déclarer dans les "globale" à certains endroits .....
.... no comment

Merci à tous et à mon avis yen à pas beaucoup qui auront mon probleme parceque sur ce coup la j'ai pas été brillant

 

[brakstar]

La maintenance de mon forum est terminée et tout marche à merveille. Quand "1" utilisateur ouvrai l'index du forum cela produisait 40 erreurs. Javais fait cette erreur et l'avais laissé depuis une semaine à peu pres. Le loggueur comptait .......

76 000 erreurs !!!!!!!!!!!!!!!!!!!!

D'ou le ralentissement, ce qui est bizare c'est que le rewriting des url marchait quand meme impécable.

Moralité de l'histoire :

Si votre serveur ralentit après une réecriture d'url, vérifiez vos déclarations de variable

 

[nodom]

bravo! :lol: