Cerco suggerimenti per bypassare PHP memory limit (delusione Netsons)

22 contenuti / 0 new
Ultimo contenuto
Cerco suggerimenti per bypassare PHP memory limit (delusione Netsons)

Salve a tutti.
Ho appena ricevuto la brutta notizia che per aumentare la memoria di PHP nei piani di hosting di Netsons bisogna necessariamente passare all'hosting VPS e sborsare 40 euro +iva /mese.
Non c'è differenza tra i due livelli di entrata (condiviso-pro e semidedicato): sono sempre 64M

Una vera fregatura.

Purtroppo abbiamo già acquistato 1 anno e non posso dire al cliente di buttare i $$$.
Chiedo quindi qualche suggerimento per abbassare il consumo di memoria PHP.

La situazione è questa: con 64M funge tutto a meraviglia tranne la modifica di un paio di content types che hanno (rullo di tamburi) più di 90 campi ciascuno. Il problema sorge quando ci sono più di 250KB di foto per nodo; a questo punto node/edit mi da WSOD.
Il picco di memoria si aggira attorno ai 50/60 M e quindi 64M non sono sufficienti.

Sto pensando che se potessi caricare le immagini separatamente, forse riuscirei a bypassare il problema ma credo che mi serva unaltro db e non ho alcuna esperienza in merito.

Ogni suggerimento, anche una pacca sulla spalla, è ben accetto
:(

Grazie

certo che queste qui sono le notizie che fanno perdere l'entusiasmo, uno magari puo' essere un genio nel realizzare un sito internet pero' dopo quando si tratta di sborsare centinaia di euro al mese ti crolla tutto addosso e ci si ritrova a vedere i propi sogni svanire....

Per php 64 mega non sono molti ma nemmeno pochissimi :)
Il problema credo che sia legato alle immagini che vengono caricate da php e manipolate hai moduli specifici che fanno cio?

Uccio wrote:
Per php 64 mega non sono molti ma nemmeno pochissimi :)

esatto. Infatti ero (sono) soddisfatto delle prestazioni e del loro costo.
Mi ha deluso il fatto che il piano successivo costi 4 volte tanto (60 invece di 15 /anno) ma la memoria php rimanga la stessa!

Uccio wrote:
Il problema credo che sia legato alle immagini che vengono caricate da php e manipolate hai moduli specifici che fanno cio?

Uso filefield/imagefield.
Dici che con upload (core) potrebbe funzionare meglio?

E se spostassi le immagini in gallerie separate, per caricarle nel nodo come viste embedded, funzionerebbe?

Grazie!

Io sentirei anche questa campana : Misterdomain ( io uso sia net che mister ).
Altri non ne vedo ( sia per prezzo che per prestazioni correlate ai costi ...).
Mi sembra cmq che più salgono le applicazioni e più salgono i costi di gestione, inevitabile.
Perchè non provi a spiegare al cliente che cosa serve e che cosa bisogna fare ( e pagare ) per avere un servizio ottimale ( del quale non sei certo >Tu che inventi o fai degli extra - costi e aggiunte varie di listino ).
Non credo sia giusto "fare un mea culpa troppo longevo" : sarebbe ora che anche la clientela capisca qualcosa in più dei 20 euro.
Posso capire che il periodo economico sia tra i peggiori mai visti ( per me dal 1974 ) e in tutti i settori : ma nessuno lavora per beneficienza.

il reparto >>
Pacche sulle spalle

Sempre più avanti... Dato che abbiamo escluso l'opzione "aumenta la memoria"...

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Chiedo quindi qualche suggerimento per abbassare il consumo di memoria PHP.

La situazione è questa: con 64M funge tutto a meraviglia tranne la modifica di un paio di content types che hanno (rullo di tamburi) più di 90 campi ciascuno. Il problema sorge quando ci sono più di 250KB di foto per nodo; a questo punto node/edit mi da WSOD.
Il picco di memoria si aggira attorno ai 50/60 M e quindi 64M non sono sufficienti.


Rullo di tamburi? Guinness dei primati direi. Novanta. Nove zero. Ye Gods.

Vediamo un pò. Questo 90 campi sono tutti singoli? Cioè sono salvati in tabelle content_type_xxx o content_field_xxx o entrambi, e se si quanti? Presumo che puoi usare Devel in locale, quindi contali!

Questo cambia la query, numero di query, quindi consumo di memoria. In questo caso è meglio un content_type_xxx. So che hai due tipi di contenuti, quindi c'è il rischio che hai tanti tabelle content_field_xxx, quindi multiple query, più consumo di memoria.

I campi vengono cachati, ma questo viene pulito quando inserisci un imagine (o cambi un valore di un capo), in tale caso tutte le query vengono eseguiti.

Non ho capito la parte "Il problema sorge quando ci sono più di 250KB di foto per nodo; a questo punto node/edit mi da WSOD". Non credo che stai riferendo alla grandezza dei file immagine, ma alla memoria quando hai aggiunto un tot di campi immagine nel nodo. Il WSOD succede visualizzando l'edit, inserendo l'immagine, o dopo il 'Salva'?

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Sto pensando che se potessi caricare le immagini separatamente, forse riuscirei a bypassare il problema ma credo che mi serva unaltro db e non ho alcuna esperienza in merito.

Questo è un idea molto sensato. Perchè credi che ti serve un altro db? Ti serve un'altro content type e basta, con un nodereference al nodo con tutti quei novanta campi. O magari il novantunessimo campo nel nodo mostro.

Ah si, back-slap: http://www.e-folio.co.uk/images/back_slap.jpg

Più imparo, più dubito.

Ciao John.

jhl.verona wrote:
Sempre più avanti... .

Beh, non so se è stata una buona idea, ma non ho trovato sistema migliore per soddisfare l'esigenza di 120 campi custom...
Sono 123 campi per l'esattezza.
Sono tutti single value eccetto le immagini (filefield)
Quindi sono salvati in tabelle content_field_xxx
Embedded Video (1)
File (2)
Float (6)
Integer (14)
Standard group (11)
Table Field (1)
Testo (87)
View reference (1)

I 2 content types condividono circa 110 campi (pensavo che condividere i campi fosse consigliato...)

jhl.verona wrote:
Non ho capito la parte ...

Penso che le immagini siano più un effetto che la causa MA, il fatto è che i nodi con tutti i campi compilati e con meno di 200-250 kb di immagini non hanno problemi; mentre se le dimensioni complessive delle immagini superano questa soglia node/edit = WSOD.
Inoltre ho un altro content type con molte immagini per nodo ma pochi campi; anche lui non ha problemi

Drupal si blocca sempre ad una chiamata a mysqli.inc, riga 303. ovvero l'ultima riga di questa funzione:

<?php
 
function db_encode_blob($data) {
  global
$active_db;
  return
"'". mysqli_real_escape_string($active_db, $data) ."'";
}
?>

Potrei avere qualche problema di encoding del testo, ma non credo.

Il WSOD si verifica regolarmente in node/nid/edit;
Quando si caricano le immagini in un nodo nuovo, il WSOD si verifica al salvataggio ma il nodo viene salvato.

jhl.verona wrote:
Questo è un idea molto sensato. Perchè credi che ti serve un altro db? Ti serve un'altro content type e basta, con un nodereference al nodo con tutti quei novanta campi. O magari il novantunessimo campo nel nodo mostro.

Si, sto provando con un approccio simile a questo: http://www.lullabot.com/articles/photo-galleries-views-attach

Speriamo che funzioni...
Grazie!

Centoventitre, uno due tre, 123... Sono molto tentato di chiedere cosa stai catalogando, ma mi fa paura...

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Beh, non so se è stata una buona idea, ma non ho trovato sistema migliore per soddisfare l'esigenza di 120 campi custom...
Sono 123 campi per l'esattezza.
Sono tutti single value eccetto le immagini (filefield)
Quindi sono salvati in tabelle content_field_xxx

Non esattamente...
CCK è una bella bestia, ma in questo caso (lasciando stare il prolema memoria) può creare problemi di inefficenza.
Per fortuna usa un cache di read, quindi per tutti i campi 2 o 200 in lettura, fa solo due query al DB. Ma dopo un cambiamento deve recreare quel cache.
Se un campo è singolo e non condiviso allora viene salvato in un unica tabella (con tanti colonne quanto i suoi campi fratellini). Quindi uno solo query di scrittura, ed uno solo di lettura - tabelle content_type_xxx.
Se un campo e multiple o condiviso con altri content type allora viene salvato in una tabella a parte. Quindi un query di scrittura, ed uno di lettura solo per ogni campo di questo tipo - tabella content_field_xxx. Nel tuo caso farà 123 query - gulp.

Ora come ora, è tardi, ma se non c'è un buonissimo motivo per condividere questi campi, o che siano multiple, è molto più efficiente (CPU e memoria) che siano in una tabella solo.

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
I 2 content types condividono circa 110 campi (pensavo che condividere i campi fosse consigliato...)

E' proprio perchè l'hai condivisi che sono in tabelle separati. Ripeto, è tardi cambiare adesso ti costerebbe una giornata di lavoro (e perderesti i dati già accumulati), quindi il mio è solo un promemoria per il futuro.

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
jhl.verona wrote:
Non ho capito la parte ...

Penso che le immagini siano più un effetto che la causa MA, il fatto è che i nodi con tutti i campi compilati e con meno di 200-250 kb di immagini non hanno problemi; mentre se le dimensioni complessive delle immagini superano questa soglia node/edit = WSOD.
Inoltre ho un altro content type con molte immagini per nodo ma pochi campi; anche lui non ha problemi

Diagnostica giusta, secondo me.

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Drupal si blocca sempre ad una chiamata a mysqli.inc, riga 303. ovvero l'ultima riga di questa funzione:
<?php
 
function db_encode_blob($data) {
  global
$active_db;
  return
"'". mysqli_real_escape_string($active_db, $data) ."'";
}
?>

Potrei avere qualche problema di encoding del testo, ma non credo.

Concordo anche su questo. E' semplicemente un punto che richiede un blocco di memoria 'sostanziale', che PHP non ha più...

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Il WSOD si verifica regolarmente in node/nid/edit;
Quando si caricano le immagini in un nodo nuovo, il WSOD si verifica al salvataggio ma il nodo viene salvato.

Anche questo è ragionevole. Per salvare richiede meno memoria, ma per releggere i dati e recreare la cache, e creare il form ci vuole molto più memoria.

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
jhl.verona wrote:
Questo è un idea molto sensato. Perchè credi che ti serve un altro db? Ti serve un'altro content type e basta, con un nodereference al nodo con tutti quei novanta campi. O magari il novantunessimo campo nel nodo mostro.

Si, sto provando con un approccio simile a questo: http://www.lullabot.com/articles/photo-galleries-views-attach

Speriamo che funzioni...


Credo di si. Non aggiunge tabelle o campi nel nodo gallery.
Ci possono rimanere delle situazioni 'edge case'. Con 87 campi testo, se vengono riempiti tutti, ecc, ecc. Ma probabilmente ci vuole tre giorni per riempire i campi ;-)
Anch'io speriamo che ci la cavo...

Più imparo, più dubito.

Quote:
Centoventitre, uno due tre, 123... Sono molto tentato di chiedere cosa stai catalogando, ma mi fa paura...

sailing boats
Quote:
Ora come ora, è tardi, ma se non c'è un buonissimo motivo per condividere questi campi, o che siano multiple, è molto più efficiente (CPU e memoria) che siano in una tabella solo.

Invece è un buon suggerimento. in effetti ho solo UNO dei content type con molti dati. L'altro ha solo 4 nodi.
Tu dici che se io NON CONDIVIDO più i campi o elimino il content type 2, le tabelle content_field_xxxspariranno e i campi saranno automaticamente trasferiti in content_type_xxx?
In questo caso sarebbe facile clonare il content type 1 e convertirlo nel content type 2 con nomi di campo diversi...
Quote:
Credo di si. Non aggiunge tabelle o campi nel nodo gallery.

Questa non l'ho capita: come faccio a creare una galleria senza un campo immagine?
I nodi galleria hanno solo 3 campi: titolo, immagini (multiple) e nodereference.
Sto facendo un test con le gallerie spostate in nodi separati, create tramite nodereference_url e visualizzate nel nodo con view_reference.
Ti farò sapere come va. in locale il picco si è abbassato a 37-42M.

Grazie ancora
:)

@Lorenzo: grazie per il conforto e i suggerimenti
;)

Interessante...

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
sailing boats

C'è l'ho. Ma fare la domanda per una boa richiedeva molto meno campi ;-)

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Quote:
Ora come ora, è tardi, ma se non c'è un buonissimo motivo per condividere questi campi, o che siano multiple, è molto più efficiente (CPU e memoria) che siano in una tabella solo.

Invece è un buon suggerimento. in effetti ho solo UNO dei content type con molti dati. L'altro ha solo 4 nodi.
Tu dici che se io NON CONDIVIDO più i campi o elimino il content type 2, le tabelle content_field_xxxspariranno e i campi saranno automaticamente trasferiti in content_type_xxx?
In questo caso sarebbe facile clonare il content type 1 e convertirlo nel content type 2 con nomi di campo diversi...

Sfortunatamente, no. Rimaranno le tabelle content_field_xxx per CT1, ma ci sarà una tabella solo content_type_xxx per il CT2 (o CT2' perchè devi cancellarlo e ricrearlo).
Puoi passare da singolo a multiple e/o condiviso, ma non puoi tornare indietro. Questo lo puoi testare nel sandbox, eventualmente. Qui un diagramma: http://drupal.org/node/112792, e qui una descrizione: http://www.lullabot.com/articles/an-introduction-to-the-content-construc... D'accordo, fanno riferimento a Drupal 5.x, ma la sostanza è ancora valido. Non mi ricordo dove ho letto del "no going back", ma è così, credimi.

Soluzioni ci sono. Magari con Features (che devi modificare e poi reimportare). Ma rimane il problema dati. Puoi usare Features per creare CT1' e CT2', ma poi devi fare un bel massaggino per creare tutti i record paro paro da CT1 a CT1' e CT2 a CT2'. Fattibile, ma ti mangerà la giornata di sicuro.
Oppure node convert (non lo conosco, ma è stato suggerito da IRC #drupal-italia)

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Quote:
Credo di si. Non aggiunge tabelle o campi nel nodo gallery.

Questa non l'ho capita: come faccio a creare una galleria senza un campo immagine?
I nodi galleria hanno solo 3 campi: titolo, immagini (multiple) e nodereference.
Sto facendo un test con le gallerie spostate in nodi separati, create tramite nodereference_url e visualizzate nel nodo con view_reference.
Ti farò sapere come va. in locale il picco si è abbassato a 37-42M.

Nope. Gallery ha due views attached. Nun c'è campo immagine multiple. E dato che ho solo scaricato il Feature, non ho la più palida idea come si fa aggiungere un views attach - mi tocca rivedere il video. Il CT Photo ha campi per il nodereference e immagine. Views attach fa la colla.

Più imparo, più dubito.

Quote:
Sfortunatamente, no. Rimaranno le tabelle content_field_xxx per CT1, ma ci sarà una tabella solo content_type_xxx per il CT2 (o CT2' perchè devi cancellarlo e ricrearlo).

In realtà, ho fatto la prova in locale:
- elimina tutti i nodi CT2
- elimina CT2
Risultato: il mio db è passato da 236 tabelle a 135 e la tabella content_type_CT1 è passata da 4 a 100+ righe occupate dai campi non più condivisi. le tabelle content_field_xxx dei campi non più condivisi sono sparite.
e, soprattutto, il sito sembra funzionare normalmente.

Mi sono illuso o forse eliminando i content type "in condivisione" il processo di condivisioni campi è reversibile?

Devo provare con features che esporta i campi condivisi come campi separati, reimportando solo il CT2 (precedentemente eliminato)

Per quanto riguarda la galleria separata: non sto usando esattamente l'approccio di Eaton: lui usa tanti nodi immagine raccolti in un nodo galleria; io uso un nodo galleria embedded nel CT attraverso view_reference (views_attach è troppo limitante e non va d'accordo con cck_fieldgroup_tabs).

Grazie dell'aiuto.
provo con features e ti faccio sapere

Ciao!

Felicissimo di essere sbagliato...

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Quote:
Sfortunatamente, no. Rimaranno le tabelle content_field_xxx per CT1, ma ci sarà una tabella solo content_type_xxx per il CT2 (o CT2' perchè devi cancellarlo e ricrearlo).

In realtà, ho fatto la prova in locale:
- elimina tutti i nodi CT2
- elimina CT2
Risultato: il mio db è passato da 236 tabelle a 135 e la tabella content_type_CT1 è passata da 4 a 100+ righe occupate dai campi non più condivisi. le tabelle content_field_xxx dei campi non più condivisi sono sparite.
e, soprattutto, il sito sembra funzionare normalmente.

Mi sono illuso o forse eliminando i content type "in condivisione" il processo di condivisioni campi è reversibile?

Devo provare con features che esporta i campi condivisi come campi separati, reimportando solo il CT2 (precedentemente eliminato)


Questo è davvero un ottimo notizie. I conti tornano, e presumo anche i dati!
Forse la nuova versione di CCK, forse la mia memoria - o mancanza di.
Comunque vuol dire che CCK è veramente magia potente.

Più imparo, più dubito.

Netson dà 2 DB nel hosting linux standard ( se non lo stavi già usando e può tornare utile lo potresti creare ).
Ho un rallentamento ( un sito su mister ) da test sono al 96° posto : forse troppi moduli o contenuti.. ai dont andesten : però con aduorz lo cliccano tutti, chissà perchè..

Speriamo in future offerte di Host a prezzo oll rait : intanto fatti pagare, per quel posso capire è un lavoro elaborato e "massiccio".

più uso il mouse e più mi fa male il pollice

Allora,
sono riuscito a sostituire CT2 (quello con pochi contenuti) con CT2' provvisto degli stessi campi ma con nomi diversi (e quindi campi diversi).
Risultato: il mio db è ora di 137 tables vs. 237.
Ricetta:
- export del vecchio CT2 (content_copy)
- cerca sostituisci (acrobatico) per sostituire le istanze di field_vattelapesca con field_new_vattelapesca
- import di CT2'
- funziona tutto? (si)
- elimina i nodi CT2
- elimina CT2
- rinomina CT2' -> CT2
so far so good. :)
ora benchmarking, poi live (speriamo)

Bohz,

cck è un gran amico ma forse tutti quei campi pretendevano un nodo vero a cui all'ultimo ci attaccavi 2-3 filds!!

Non ho capito!
cosa intendi per "nodo vero" e "2-3 fields"?
Grazie!

OK,
da quel che ho capito, ma correggimi se sbaglio, il tuo nodo è un nodo "base" a cui ci hai attaccatto 90 CCK fields il problema dal mio punto di vista non sono tanto i 90 campi di per se ma "i novanta campi gestiti da cck".
CCK è veramente comodo ma un nodo come il tuo per "prestazioni" avrebbe voluto essere implemetato da codice. Il tuo nodo "particolare" havrebbe avuto tutti i campi necessari e poi sarebbe stato esteso con CCK per la parte delle immagini che da codice è lunga e dispendiosa.

Tieni presente che scrivere un nodo con campi di testo è una cosa abbastanza veloce (parti dal modulo di esempio di nodo ed aggiungi tutto cio che ti serve)

Com'è andata a finire?

<a href="mailto:bohz@drupal.org" rel="nofollow">bohz@drupal.org</a> wrote:
Allora,
sono riuscito a sostituire CT2 (quello con pochi contenuti) con CT2' provvisto degli stessi campi ma con nomi diversi (e quindi campi diversi).
Risultato: il mio db è ora di 137 tables vs. 237.
...
so far so good. :)
ora benchmarking, poi live (speriamo)

Più imparo, più dubito.

male.
non ce la fa con solo 64M.
Dovrei fare come suggerisce uccio ma non sono molto bravo e, onestamente, il budget è troppo basso.
ancora devo trovare una soluzione.

Grazie lo stesso John

Inoltre hoster con piu di 64MB sono rari quindi devi andare su un vps :(

Ciao a tutti,
intanto grazie per le informazioni interessanti che trattate sempre, per un pivellino come me sono manna dal cielo!

Cmq io per realizzare il sito dell'azienda dove lavoro ho utilizzato il VPS hosting Linode. La configurazione base costa solo 19.95$ al mese (16GB Hard disk, 360MB RAM, 200GB Tranfer/month) che nel mio caso va più che bene.
Mi sembra un rapporto qualità prezzo abbastanza buono (per la poca esperienza che ho).

Spero di poter essere stato utile.