Mise à niveau après problème la charge du serveur![]()
Mise à niveau après problème la charge du serveur![]()
Quelqu'un at-il une idée de la taille du cache de fichiers pourrait obtenir avant qu'elle n'ait un impact négatif sur les performances?
Database Cache cache traductions seulement. Non tout le contenu HTML. Alors, quand une certaine page traduite est générée, puis la première page normale est générée et après qu'il est analysée et traduite. Pendant cache DB traduction est utilisée et phrases traduites sont prises à partir de là. Juste des phrases - et non HTML entier, parce que chaque fois traductions peuvent être différentes (ie différents privilèges des utilisateurs, le contenu a changé). Une page HTML peut avoir des centaines de phrases à traduire - vBET prend contenu entre les balises HTML. Merci DB cache ces traductions ne doivent pas être prises à chaque fois à partir de Google - ce qui consomme beaucoup de temps - au lieu de cela, ceux-ci sont prises à partir de votre DB locale. Still - Page normale doit être généré et après cette traduction.
Cache de fichiers pour les personnes séjournant ne fonctionne que pour les clients. Merci de ne pas avoir à se soucier que les utilisateurs ont des privilèges différents et voir des choses différentes. invités verrez le même contenu. A cause de cela nous n'avons pas à analyser et traduire des résultats morceau par morceau à chaque fois - nous ne pouvons tout simplement pas l'un un certain temps et la mémoire cache de sortie HTML complet. Donc dans ce cas lorsque la page complète n'est pas mise en cache ou cache le contenu est trop vieux, puis la traduction normale survient - comme décrit précédemment. Mais cette fois à la sortie très fin HTML complet est écrit dans le fichier. Alors la prochaine fois quand même requête provient d'invités que nous ne génèrent pas de même du contenu normal de la page - nous avons simplement flux à des clients déjà en cache de fichiers HTML. C'est pourquoi nous sauver beaucoup de requêtes SQL, CPU et mémoire. Nous venons de donner au contenu de l'utilisateur à partir de fichiers statiques. C'est pourquoi il est important de déterminer combien de temps ce cache sera valide. Parce que si quelque chose va changer - c'est à dire après de nouveaux arrivent au fil, puis les invités ne verront pas ce nouveau poste jusqu'au fichier déjà en cache expire. Après cela, lors de la requête suivante, la page à nouveau normale sera généré, traduit et mis en cache - et ce contenu invités verront-dire pendant une heure (configurable). Ils ne verront pas de changements jusqu'à ce que le fichier en cache expire à nouveau. Bien sûr, vos utilisateurs pourront tout voir, parce qu'il ne fonctionne que pour les clients (donc pour les robots aussi, parce que les robots rampent votre forum en tant qu'invités).
S'il vous plaît dites-elle aider et, en cas de questions il suffit de demander - nous ferons un plaisir de décrire plus![]()
dans le fichier /images/vBET/Flags/vBET.CSS
S'il vous plaît mieux décrire ce que signifie "bizarre" - peut-être nous allons pouvoir vous aider. Aussi, nous conseillons d'utiliser pour des choses telles Firefox avec le plugin Firebug - il vous permettra de vous montrer exactement ce qui les styles CSS sont utilisés pour les éléments spécifiés. Il est vraiment utile![]()
Norme. Assurez-vous juste que vous faites tout cela. Principalement les utilisateurs ne veulent pas télécharger des images à nouveau - vous avez dans cette version. Maintenant nous avons une image de tous les drapeaux. Si vous n'avez pas fait de mise à jour complète, vous verrez des drapeaux cassé.
Je sais que pour tout le monde sa version est plus importantEt nous ne voulons pas d'argumenter avec ce
Dans ce cas vBET3.x est anticipée pour bonne raison: la qualité. Nous ajoutons de nouvelles fonctionnalités importantes (Cache de fichiers pour les personnes séjournant) dans cette version et c'est beaucoup plus facile d'ajouter dans vB3, parce qu'il n'y a aucune URL conviviales, et nous traduisons seulement thread URL pour vBulletin. Dans le cas de vB4, c'est plus compliqué - Friendly URLs doivent être pris en charge, et nous traduisons beaucoup plus de types d'URL. Mettre tout d'abord dans vB3. nous a permis de le tester très bien sur les forums de real, vérifier qu'il fonctionne très bien, peut-être montrera que quelques bugs avant elle aller à vB4. Et après que nous sommes complètement sûrs que c'est bien, il faut encore ajouter dans vB4 aditional soutien (URL de Friuendly, plus translted URL). C'est pourquoi ce temps vBET3.x est plus tôt et nous avons encore besoin 2 semaines pour vBET4.x. Et merci que vous obtiendrez des solution qui ont de très bonne qualité, ewen si c'est plus compliqué qu'affaire de vB3
Il devrait y avoir rien de tel que l'impact des performances négatives en raison de cache de fichiers. C'est parce que le cache de fichiers ne pousse ... Nous créons fichier séparé pour chaque URL de requête. Ainsi, chaque fichier de cache est simplement un fichier HTML statique (sortie en cache de la demande). Lorsque votre serveur caches vBET plus en plus crée simplement des fichiers de plus en plus. Donc chaque fois que tel fichier est lu:
1. Il est lu seul résultat pour cette URL particulière
2. Nous avons même ne pas le lire à la mémoire - tout simplement le flux au client en utilisant la fonction PHP: readfile
A cause de cela même si votre page de résultat est vraiment grand - fichier cache l'est aussi grande, elle n'aura aucun impact sur les performances négatives, car il sera simplement ce fichier flux un sans même lire ensemble, il en mémoire. Alors vous verrez des avantages non inconvénients.