@fello said:

Posso farmi rimborsare per questo servizio a dir poco scadente??

Si, provaci ma avvalendoti di fatti e prove circostanziati.

dipende dal contratto che hai. E molte volte ci puoi fare ben poco. La tua unica soluzione è trasferirti.

dipende dai TOS.
I Term of service sono sempre da leggere ed analizzare ogni qualvolta che si decide di hostare il proprio sto da un determinato provider.

di solito le compagnie di hosting non fanno firmare contratti ma per ogni acquisto si affidano al loro TOS e consigliano la lettura al proprio cliente.

saluti

Discussione invecchiata, ma interessante perché ancora molto visibile (e sempre attuale). Secondo me a volte i problemi legati all'errore 500 dipendono dal provider, ma nella maggior parte dei casi sono imputabili ad una cattiva scelta del servizio hosting. Se non c'è ponderazione, ovvero, se non si cercano le condizioni ideali in termini di sicurezza e affidabilità rispetto al "peso specifico" del proprio progetto web, è chiaro che vengono meno le condizioni di tranquillità necessarie a condurre un business sul web. Non è quindi il provider, ma il servizio. Da questo punto di vista a me piacciono molto i server virtuali, proprio perché sono scalabili.

Ciao francescomargherita, sono perfettamente in sintonia con quanto affermi!
Non lo sono sulla questione del server, parlerei di webserver in tutta onestà... Nginx di fatto è diventato il killer di Apache, e da sistemista mi domando come mai i più grossi fornitori di servizi ancora puntano su Apache. O si rifanno a trucchi vecchi come il mondo di utilizzare Nginx come proxy per i file statici e poi adottano Apache per servire quelli dinamici (sulla porta 80 in definitiva lavora Apache)...
Utilizzare solamente Nginx oppure Lighttpd è chiedere troppo? È così difficile configurare questi webserver? Credo proprio di no, ci sono aspetti sistemistici ai quali nessuno ancora si approccia e commerciali che fanno leva sulle abitudini generali!
Il tuo problema è comune e riguarda la stragrande maggioranza di siti su hosting condiviso dove Apache la fa ancora da padrone.
Nginx è attualmente la soluzione migliore, è nato per essere in grado di servire fino a 500 milioni di richieste al giorno (dati wikipedia del 2008)... Apache non supera le 10.000 connessioni contemporanee (il famosissimo c10k problem) e consuma interamente la ram dei server.
Il problema non si supera neanche con un dedicato, quindi a mio modesto avviso la sola chiave di lettura per scalare seriamente queste problematiche sta nel cambiamento radicale di rotta... tutto il resto è noia!

Ciao francois,

il problema non sta nelle capacita' del sistemista, configurare nginx e' roba da "principianti", il problema sta lato utente ... gia' molti utenti hanno problemi con il semplice rewrite di Apache cotto e stra cotto, non oso immaginare cosa avverrebbe se un domani, queste regole smetteranno di funzionare a favore di nginx, e' vero, esistono i convertitori delle rewrite, ma una buona fetta di mercato e' data da utenti alle prime armi, che sicuramente, ad un cambio del genere andranno in crisi.

Riguardo l'errore 500, non sempre e' errore del provider, in generale comunque che sia errore del provider o dell'utente e' sempre disponibile un error_log (nelle aziende dove viene permessa la gestione) il quale indica inequivocabilmente la natura dell'errore ed, eventualmente la colpa

Ciao

Però i limiti di Apache sono evidenti... se consideriamo un sito che utilizza un comunissimo CMS, configurare Nginx è un gioco da ragazzi, con una buona tolleranza verso gli errori!
Il cambio di rotta è già iniziato, è solo questione di tempo!

Ciao,

si i limiti sono evidenti, ma in ambiente shared, trovo difficile che nginx possa dominare apache se non come reverse-proxy, su plesk ad esempio, e' possibile usare php-fpm+nginx direttamente dall'utente, ma e' una configurazione "manuale" che andra' a fare l'utente quindi un utente che andra' a fare questo, sicuramente, sa cosa fa, dubito fortemente che questa funzione possa essere utilizzata dagli utenti entry level.

Per applicazioni complesse esempio su ambiente dedicato come un vps o dedicato, siamo noi stessi a installare nginx al posto di apache, spiegandone i vantaggi ma anche in questo caso spesso capitano utenze che preferiscono rimanere alla "vecchia maniera".

Ciao.

Un entry level se guidato e assistito ha solo vantaggi a utilizzare Nginx o Lighttpd (attualmente sto testando anche OpenLiteSpeed su un server locale)...
Su pannelli proprietari non ho mai lavorato, preferisco soluzioni aperte da adattare alle mie esigenze ( e che modifico a mio piacimento)...
Se restiamo ingabbiati all'interno di soluzioni chiuse saremo sempre un passo indietro rispetto agli altri... Le vecchie maniere sono superate...
Ho la testa duro e ne sono cosciente, alla fine il risultato finale è identico sia scegliendo l'uno o l'altro o l'altro ancora... la perfezione non esiste, ma quello che cerco è qualcosa che si accosti ad essa e alla semplicità e alle performance che fino ad ora solo Nginx mi ha saputo garantire.
Un abbraccio...

Ragazzi avete rispolverato un thread del 2006.

Riguardo al webserver Nginx offre prestazioni maggiori rispetto ad Apache, ma in alcuni casi è incompatibile sopratutto su un Hosting shared (come scritto in precedenza da vHosting), questo è il motivo per cui noi usiamo Litespeed Enterprise sui nostri server, veloce con un buon utilizzo della cache e del buffer, affidabile e purtroppo molto caro.

francois007 effettua dei test con OpenLiteSpeed noterai la potenza di questo webserver, tieni presente che nella versione Free manca la possibilità di usare la cache e altro.

Ciao.

Ciao Xlogic, ti ribatto punto su punto su quanto affermi (tranne che su LiteSpeed).

1. Nginx non è incompatibile su hosting shared, basta leggere questo wiki http://wiki.nginx.org/Configuration... se l'incompatibilità riguarda i pannelli di hosting noi utilizziamo ISPConfig, il problema non ci riguarda se Parallels, cPanel & company closed source non lo sono;
2. LiteSpeed ci sembra interessante, ma il benchmark attuale (sia su Debian stabile che testing) non ci consente di migrare a questo webserver;
3. Non è vero che OpenLiteSpeed non utilizza la cache, il modulo va configurato manualmente http://open.litespeedtech.com/mediawiki/index.php/Help:Modules:Cache

Ribadisco, restare ingabbiati in soluzioni chiuse è il più grande errore che si commette quando si lavora su una qualsiasi distro Linux.

Good hacking...

Per un singolo sito Nginx va bene, ma su un hosting condiviso consiglio Litespeed.

Benchmark: http://postimg.org/image/k5vumbdxl/

Con il modulo di OpenLiteSpeed per la cache gli utenti del server dovrebbero utilizzare .htaccess per configurare ed utilizzare questo tipo di cache. In generale, questo modulo per il caching delle pagine non è raccomandato per l'hosting condiviso, perché è difficile da configurare con molti siti diversi.

Ciao.

Nginx lavora benissimo su condiviso... su OpenLiteSpeed sto già lavorando per superare il problema della cache su piattaforma condivisa lavorando lato codice...
I miei server sono Nginx based, ci gira di tutto (joomla, wordpress, drupal, phpmotion, dolphin, script proprietari etc. etc. etc.)... e sto parlando di shared hosting... a questo punto vorrei capire perché non si adatta!

Francois007, non ho scritto che Nginx non si adatta allo Shared, ho scritto che su un hosting condiviso consiglio Litespeed. Nginx è ottimo sopratutto se usato con Varnish, ma a livello di shared secondo me Litespeed è più duttile, veloce e compatibile.

Non vorrei iniziare una gara a che ce l'ha più lungo :), ripeto Nginx è ottimo.

A giorni pubblico la modifica lato codice di OpenLiteSpeed
Sono graditi i feedback da parte di tutti, ma soprattutto da parte tua se vorrai testarlo...
Ciauz...

ok, ciao.

fello alla fine come hai risolto? mi sono trovato in una situazione simile anch'io