E’ anche vero che un pensierino già ce l’avevo fatto, quindi la scelta era già mezza presa.
Però ho commesso l’errore di valutare superficialmente lighttpd, dicendo che non è molto intuitivo per chi non lo usa abitualmente, invece non è cosi mi è bastato leggere un minimo di documentazione per capire come impostarlo quantomeno alla base per farlo andare.
Adesso però i rusltati si vedono e si sentono soprattutto:
kratos:~# free
total used free shared buffers cached
Mem: 2066168 1305236 760932 0 114304 350820
-/+ buffers/cache: 840112 1226056
Swap: 3939444 0 3939444
notare lo swap completamente inutilizzato.
kratos:~# uptime
15:30:32 up 3:58, 2 users, load average: 0.17, 0.25, 0.28
Il carico macchina non sorpassa mai lo 0.501, ed i tempi di risposta mi sembrano abbastanza sopportabili; a proposito mi confermate quanto sto dicendo? :P
Adesso ho riabilitato i virtual host più importanti giusto per terminare il disservizio, stasera passerò ai servizi secondari.
Purtroppo da apache il modo di gestire il web server cambia radicalmente, soprattutto nella sintassi, un esempio di virtualhost per esempio è questo:
$HTTP["host"] =~ "(^|\.)ilportalinux\.it" {
server.document-root = "/path/to/document/root"
server.errorlog = "/var/log/lighttpd/ilportalinux/error.log"
accesslog.filename = "/var/log/lighttpd/ilportalinux/access.log"
}
###
questa però è proprio la configurazione base del virtualhost, per una piattaforma come wordpress bisogna giocare un attimino con le regole di rewrite, e cosi il virtualhost diventa:
$HTTP["host"] =~ "(^|\.)ilportalinux\.it" {
url.rewrite = (
"^/(wp-.+).*/?" => "$0",
"^/(sitemap.xml)" => "$0",
"^/(robots.txt)" => "$0",
"^/(xmlrpc.php)" => "$0",
"^/(.+)/?$" => "/index.php/$1"
)
server.document-root = "/path/to/document/root"
server.errorlog = "/var/log/lighttpd/ilportalinux/error.log"
accesslog.filename = "/var/log/lighttpd/ilportalinux/access.log"
}
###
in questo modo possiamo utilizzare i "clean url", ed essere molto più SEO friendly. Infine nel file robots.txt del blog ho inserito:
User-agent: *
Disallow: /cgi-bin
Disallow: /wp-admin
Disallow: /wp-includes
Disallow: /wp-content/plugins
Disallow: /wp-content/cache
Disallow: /wp-content/themes
Per far andare wordpress, e praticamente qualsiasi piattaforma, dobbiamo però attivare il modulo "mod_fastcgi" di lighttpd, altrimenti non potremo utilizzare il linguaggio php.
Per fare andare piattaforme come drupal invece la conformazione del virtualhost cambia un pò, al posto delle regole che abbiamo aggiunto per wordpress dobbiamo mettere:
index-file.names = ( "index.php" )
simple-vhost.server-root = "/path/to/document/root"
simple-vhost.default-host = "projects"
simple-vhost.document-root = "connector"
ed abilitare il modulo "mod_simple_vhost".
Se qualcuno è interessato a migrare a lighttpd che lo dica magari posso scrivere un tutorial apposito. Per adesso continuo a tenere tutto incrociato, non vorrei cantare vittoria troppo presto.
- in realtà non l’ho mai visto passare lo 0.30 ma voglio stare largo
[↩]
| |













Beh finalmente problemi risolti allora
Meglio così x te
Ciao M0rF3uS, dato che faccio girare tutto sotto apache da oltre un secolo, mi interessa sapere cosa sia successo, non ho trovato dettagli sull’accaduto. La mia è pura e semplice curiosità professionale
Prima che tu scriva qsi cosa, mi cospargo il capo di cenere da solo… ho trovato il post in cui parli dell’accaduto. Mo me lo leggo…
Ciao Zio,
in realtà quel post non descrive esattamente la causa, anche perchè…non la so…improvvisamente il server ha iniziato ad avere carichi allucinanti (oltre i 100) e vedevo un botto di processi di apache in coda.
Credo che il problema sia in qualche plugin bacato, ho sospetti su wp-gravatar che è stato appunto disattivato. Questo sospetto lo ho perchè i rallentamenti li ho avuti anche con lighttpd solo che nei log mi mostrava una query che andava in errore, che riguardava per l’appunto quel plugin.
Ne ho approfittato anche per cambiare perchè in quei pochi minuti in cui ho provato lighty alla ricerca della soluzione vedevo all’istante che i tempi di reazione erano molto più bassi (si anche in condizioni di carico eccessivo quando il problema non era risolto).
Ti va di copincollarmi una riga di log con la query incriminata?
Spetta che non so se la trovo
(mod_fastcgi.c.2610) FastCGI-stderr: WordPress errore sul database MySQL server has gone away per la query SELECT option_value FROM personal_options WHERE option_name = ‘bruk_wavatar_default’ LIMIT 1 fatta da require, require_once, include, get_footer, locate_template, load_template, require_once, get_sidebar, locate_template, load_template, require_once, dynamic_sidebar, call_user_func_array, WP_Widget->display_callback, WP_Widget_Recent_Comments->widget, get_comment_author_link, apply_filters, call_user_func_array, show_gravatar, get_option
su apache questi log non li trovi però, infatti me ne sono accorto proprio grazie a lighty