Navigazione

    Privacy - Termini e condizioni
    © 2020 Search On Media Group S.r.l.
    • Registrati
    • Accedi
    • CATEGORIES
    • Discussioni
    • Non letti
    • Recenti
    • Hashtags
    • Popolare
    • Utenti
    • Stream
    • Interest
    • Categories
    1. Home
    2. slaogiweb
    3. Discussioni
    S

    slaogiweb

    @slaogiweb

    • Profilo
    • Chi segue 0
    • Da chi è seguito 0
    • Discussioni 5
    • Post 7
    • Migliore 0
    • Gruppi 0
    Iscrizione Ultimo Accesso
    Località Milano Età 43
    0
    Reputazione
    8
    Post
    0
    Visite al profilo
    0
    Da chi è seguito
    0
    Chi segue
    User Newbie

    badges

    0
    Bookmarks
    0
    Voti
    0
    Ringraziamenti
    0
    Miglior risposte
    Inizia una nuova discussione
    di cosa vuoi parlare?

    Discussioni create da slaogiweb

    • Topic
      Post
      View
      Votazioni
      Post
      Attività
    • S

      Php, MySQL e Google Maps - Troppi I/O contemporanei
      Coding • • slaogiweb  

      2
      391
      Visualizzazioni
      0
      Votazioni
      2
      Post

      T

      Ciao,
      non è un tantinello esagerato ogni 2 secondi?
      Valuta l'utilizzo di tabelle di tipo Memory, se per ciò che devi fare tu sono utilizzabili, in maniera da non dover scrivere continuamente su disco.

    • S

      Scalabilità di un'applicazione (eccessive richieste al DB)
      Hosting e Cloud • • slaogiweb  

      6
      619
      Visualizzazioni
      0
      Votazioni
      6
      Post

      S

      Più master dedicati alla scrittura con MySQL non puoi farlo a meno di non gestire il tutto con un engine che non sia né innodb né myisam (si chiama NDB).
      puoi inziare con una soluzione MASTER-SLAVE e splittare le queries di lettura solo sullo slave.

      Poi andrei a verificare le impostazioni del my.cnf per ritarare il tutto.

      Dipende tutto dal budget che hai per il progetto.

    • S

      Cloud, Scalabilità e Load balancing, un chiarimento.
      Hosting e Cloud • • slaogiweb  

      6
      787
      Visualizzazioni
      0
      Votazioni
      6
      Post

      D

      Senza entrare nei dettagli, il load balancing è una buona soluzione se lo abbini a una struttura cluster o High Availability (HA), reale o virtuale.
      Generalmente, per server (o siti) molto trafficati, si opera con questa struttura MINIMA:
      un router fisico che fa da balancer, ovvero smista il traffico in ingresso verso la rete interna;
      due server in cluster reale o virtuale (che sono la "rete interna")

      I due server in cluster possono essere in cluster reale o virtuale. Cluster reale significa che sono due server solitamente identici in tutto e per tutto con configurazioni software e hardware particolari (tipicamente usano un NAS per condividere i dati e software specifici come p.e. MySql Cluster), cluster virtuale significa che operano più che altro a livello software senza usare però software o hardware appositamente studiati.
      Cerco di spiegare meglio il lato "virtuale". Per sincronizzare i dati tra i due server si può operare ad esempio con MySql configurato in replica master-master, con la parte web (diciamo apache, ma è indifferente) che si sincronizza tramite un software tipo unison e la parte "servizi aggiuntivi" (chessò Dns, ftp ecc) che operano indipendentemente e senza replica.

      In poche parole questa è la situazione standard che si ha con sistemi LB e HA, cioè Load Blanaced e in High Availability.

      Detto questo, una soluzione così a parte essere costosa, ha poco senso se il sistema è unico, se ne ha il pieno controllo e non raggiunge traffico di migliaia di utenti al secondo

    • S

      URL Rewrite e SEO
      SEO • • slaogiweb  

      2
      560
      Visualizzazioni
      0
      Votazioni
      2
      Post

      federico.sasso

      ciao Francesco,
      cercherò di risponderti nel modo più preciso possibile. Perdonami se userò termini troppo tecnici, o se al contrario userò semplificazioni troppo banali. Non farti problemi a chiedere ulteriori chiarimenti.

      @slaogiweb said:

      Non mi è chiaro come tutte queste pagine/post possano essere lette bene dai motori di ricerca e da google nello specifico (in fondo si tratta di informazioni che si trovano nel database e vengono visualizzate solo se richiamate dall'utente). Devo usare qualche accorgimento particolare? esiste qualche tecnica di scrittura doverosa in questi casi?
      Il motore di ricerca nel visitare il tuo sito si comporta (quasi) del tutto come un visitatore bipede, riceve su uno stream HTTP dei contenuti HTML, né lui né il bipede sanno che originariamente il dato non era su un file fisico ma su DB e generato a run-time (e se così non fosse, se la tua applicazione web esponesse un dettaglio implementativo, avresti dei seri problemi di security).
      Da questo punto di visto non ti devi quindi preoccupare: genera un documento HTML corretto, e il motore di ricerca lo tratterà nel modo corretto.

      Il motore di ricerca in realtà qualche aiutino - sebbene non strettamente necessario - lo gradisce eccome:
      Oltre a html/title e meta-description "SEO-friendly", utili anche ai soliti bipedi che leggono la SERP, al fine di migliorare la "crawlabilità" e "indicizzabilità" del sito, e qui "canonical link" in primis, robots-meta-tag, robots.txt file, etc... permettono di specificare come il motore di ricerca debba navigare e interpretare i tuoi contenuti.
      Il sito giorgiotave.it è un'ottima risorsa per tuti questi aspetti.

      Nel prossimo punto aggiungerò un po' di dritte riguardo gli URL.

      Certo, ci sono anche differenze nel modo in cui gli spider dei motori di ricerca visitano il tuo sito, rispetto ai normali utenti: quasi tutti i bot

      non utilizzano cookie, quindi non fare affidamento a concetti di sessione server googlebot in particolare non popola l'attributo HTTP accept-language, quindi non dare per scontato questo esista per fare eventuali redirect

      @slaogiweb said:

      Volevo chiedervi anche qualche informazione sul metodo di scrittura dell'url.
      Nella realizzazione di un motore CMS/Blog/wiki o similia, uno dei principali aspetti cui prestare attenzione è tenere una struttura di URL chiara, e evitare che lo spider veda contenuti identici con URL diversi, dove con "URL diversi" si intende anche la stessa pagina .php (nel tuo caso), con parametri querystring diversi. Quindi attento per esempio a commenti, versioni mobile, versioni stampabili, thread/sotto-thread/botta-risposta etc...

      La motivazione è che il motore di ricerca attribuirà meno valore ai contenuti del tuo sito se li ritrova duplicati in diversi URL. Qualora non riuscissi a evitarlo, dovrai perlomeno fare sì che solo una versione sia crawlabile e/o indicizzabile (tipicamente con robots-meta-tag, robots.txt, attributi nofollow su link interni, etc...)

      La struttura degli URL che deciderai dipenderà in parte dal framework che andrai a costruirti, per esempio se seguirai un approccio ispirato alla Rails, probabilmente avrai una struttura di un tipico sistema MVC, simile agli URL del protocollo REST; è un sistema che permette con poca attenzione di creare URL "SEO friendly", che non fa uso di parametri in querystring.

      Altra cosa cui devi prestare attenzione è l'uso dei separatori negli URL generati dinamicamente, per esempio se generi un URL "parlante" usando il titolo del post.
      Buona norma è sostituire gli spazi con dei "-" (carattere "meno"), e non degli "" (carattere "underscore"): sebbene motori di successo come quello alla base di Wikipedia usino gli underscore, e Big G non sembra penalizzare proprio Wikipedia, Google non considera lo "" un separatore e incoraggia l'uso del "-".

      Spero d'esserti stato utile.
      (se non fossi stato chiaro, dimmelo!)

    • S

      Redirect per versione mobile
      Help Center: consigli per il tuo progetto • • slaogiweb  

      1
      779
      Visualizzazioni
      0
      Votazioni
      1
      Post

      Nessuno ha risposto