Risposte nei forum create
-
AutorePost
-
San PietroburgoPartecipante
La prima cosa da fare e lavorare sul sito in locale sino a raggiungere un’installazione veloce, performante e che non crea troppi problemi al server. Dopo di ciò si sostituisce quella online a colpo sicuro e cioè senza fare disastri nel sito in produzione.
Per continuare con i suggerimenti abbiamo bisogno di “vedere” il sito, quindi scrivici una url.
San PietroburgoPartecipanteeasyPHP è un webserver, completo, che si installa nel proprio computer, come MAMP, XAMPP ed altri. Probabilmente però è il più facile da utilizzare.
Non serve per imparare il linguaggio PHP, bensଠper avere in locale una esatta copia del sito in produzione (quello online); quindi si può lavorare, modificare, sperimentare, senza fare danni.. Mai mettere le mani nel sito web, meglio provare prima le modifiche in locale e dopo replicarle online.
San PietroburgoPartecipanteCon programmi come easyPHP si possono leggere i log del server, gira nel proprio computer e si può attivare il debug di WordPress, si può utilizzare un programma di benchmark ( come quello di Apache, qui un esempio: http://go2linux.garron.me/linux/2010/04/how-benchmark-stress-your-apache-nginx-or-iis-server-718 ) per simulare visite alle pagine, migliaia di visite, e testare il sito.
San PietroburgoPartecipanteIn locale significa che è possibile utilizzare easyPHP od altri programmi, installarsi tutto il sito web sul proprio computer e senza dover toccare quello online; apportare migliorie e modifiche, osservare cosa consuma risorse, correggere errori, ecc., etc., sino a renderlo performante. Dopo di ciò si sostituisce quello nel server e nel giro di pochi minuti.
Le url che si mettono nelle pagine quando portano ad altri contenuti dello stesso sito, andrebbero scritte relative, ossia senza il www od http e il nome del dominio, bensଠpartendo dal carattere “/” in avanti. Molte url al proprio sito scritte, invece, assolute con il webserver Apache e PHP portano a maggiori consumi di risorse.
Vedere il sito serve eccome! Proprio come il medico difficilmente potrebbe fare una diagnosi senza osservare il paziente.
San PietroburgoPartecipanteSono dell’idea che lo sconforto gioca brutti scherzi; ma prima di cancellare tutto aspetta.
Potresti scrivere la url del sito qui, cosa che sino adesso non hai fatto, cosଠalcuni di noi potranno vedere le pagine e suggerire delle soluzioni. Per esempio:
Non hai detto se fa uso di un plugin di cache. E’ caldeggiato w3tc configurato a dovere;
se le immagini sono ottimizzate per il web. Si può fare, con pazienza, in locale da un backup e poi sostituire quelle nel server;
se le url interne al sito sono state scritte assolute o relative. Se assolute, si lavora in un backup del database in locale, riscrivendole corrette, per poi sostituire quello in produzione.
Tutte cose che incidono sul consumo di risorse del server.
19 Novembre 2012 alle 20:10 in risposta a: Consumi ram Worpress quando su pubblicano articoli #98832San PietroburgoPartecipanteSe il sito ha effettivamente 4 o 5 mila visitatori giornalieri (per effettive intendo i dati di analytics di google) significa che le pagine viste possono oscillare tra le almeno 6 e le 20 mila.. Un sito web che ha questi numeri non potrà stare in nessun servizio di hosting condiviso, nemmeno quelli americani che costano di più ma offrono maggiori risorse. Ovviamente fa eccezione wpitaly, ma dietro ci sono esperti (Steve e Wolly) che hanno limato il più possibile e configurato le applicazioni per ottenere il massimo; cosa assai improbabile per i normali utilizzatori. Oltretutto nei blog creati con WordPress si fa largo uso di immagini e queste incidono molto sul consumo della memoria del server, specie quando non ottimizzate.
Nel file .htaccess esistono vari modi per bloccare crawlers indesiderati e si può scrivere questo, giusto per fare un esempio, appena prima o dopo delle regole che scrive WordPress:
RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} (Baiduspider|altrobot|altrobot|altri ancora) [NC]
RewriteRule .* - [R=403,L]
Si dividono i vari User Agent con il carattere pipe “|” e se ne può inserire quanti necessari; come anzidetto terrei fuori dal blocco google e bing.
Altri andranno bloccati scrivendo il loro numero IP, giacché ne esistono alcuni che non hanno un vero e proprio identificativo (User Agent).
Per scovarli, come per vedere quali sono i bot che ravanano troppo il sito web, va letto il file di log del server con pazienza, specie per quegli orari in cui va in errore.
Direi anche che è inutile andare nelle impostazioni di Webmaster Tools di Google per imporgli maggior lentezza, il bot di google impara da se la velocità con cui leggere le pagine.
Aggiungo inoltre che sarebbe inutile agire dal file robots.txt, poiché i bot di alcuni servizi invadenti se ne infischiano delle regole che andiamo a suggerire con quel file.
19 Novembre 2012 alle 13:28 in risposta a: Consumi ram Worpress quando su pubblicano articoli #98815San PietroburgoPartecipanteVedo, si tratta dei nuovi servizi host col cappio al collo; superate le risorse disponibili il sito va offline, bella roba! Quando si ha un sito con molti contenuti e trafficato sarebbe bene star lontani da quelle tipologie di hosting.
L’unica cosa che puoi fare (se non desideri migrare e spendere di più) è intervenire nel file .htaccess, bannando i crawlers che non desideri ravanino le pagine.. Ovviamente ad esclusione di Google, Msn (oggi Bing) e pochi altri.
19 Novembre 2012 alle 12:19 in risposta a: Consumi ram Worpress quando su pubblicano articoli #98808San PietroburgoPartecipanteLa domanda era tra le righe, ti trovi in share server (anche detto share hosting), in un virtual server oppure su di un dedicato?
San PietroburgoPartecipanteTra l’altro visionando l’home page mi sono accorto che nel footer cè una piccola faccina che sorride, cosa che assolutamente non vorrei
Quella, se non ricordo male, è dovuta al contatore delle visite di WP. Per non averla ti basta levare il plugin e sostituirlo con un altro.
la faccina si toglie dalle opzioni del plugin delle statistiche senza doverne cercare uno nuovo.
-
AutorePost