Back-end su SharePoint: performances accessi concorrenti?

di il
6 risposte

Back-end su SharePoint: performances accessi concorrenti?

Buongiorno a tutti.

Premetto che utilizzo Access da poco più di 3 mesi, quindi il livello è quello che è..Portate pazienza.

Ho sviluppato un database nella azienda in cui lavoro, che serve agli utenti per annotare vari tipi di informazioni commerciali.

A livello di front-end, l'applicazione è strutturata con un sistema di log in (e vari livelli di utenza), in modo che ogni utente gestisca solo determinati dati.

Ora che l'applicazione in sé sarebbe pronta all'uso, sto riscontrando dei grattacapi nella messa in rete della stessa, per renderla utilizzabile all'utenza.

La mia idea è dividere il database, mettendo il back-end in rete e distribuendo il file front-end agli utenti che lo utilizzano avviandolo dal proprio desktop ed eseguendo il log in.

Ho fatto dei test caricando il back-end nella rete condivisa aziendale, ottenendo un riscontro per niente positivo in termini di performances.

L'applicazione già di per sé, diciamo, non brilla per velocità se ad utilizzarla è un solo utente, ma tutto sommato si lascia adoperare con efficacia. Quando gli accessi diventano 2 o 3 contemporaneamente, diventa inutilizzabile.

Calcolando che devono caricare dati una quindicina di persone, nella peggiore delle ipotesi anche contemporaneamente, il problema non è da poco. Una soluzione "d'emergenza" che sto considerando è caricare sulla rete aziendale un back-end per ogni utente, ma l'idea non mi piace per niente considerato che non è detto risolva completamente il problema velocità e, inoltre mi troverei a dover rimettere insieme i pezzi di 15 database separati. Mi pare proprio un lavoraccio, letteralmente.

Come da titolo, stavo appunto considerando di utilizzare degli elenchi in un sito SharePoint come bak-end, confidando che come soluzione sia più performante della precedente, riuscendo a non rallentare l'app front-end con molti utenti connessi.

Avete esperienze a riguardo? Sto cercando di capire se sto riponendo false speranze o meno in Sharepoint.

Non ho ancora avuto modo di testare suddetta soluzione perché sono tutt'ora in attesa delle varie autorizzazioni in azienda, però non ci dormo la notte

6 Risposte

  • Re: Back-end su SharePoint: performances accessi concorrenti?

    Ovviamente da inesperto come te ti dico le mie idee ma prendile con le pinze.... ti diranno sicuramente meglio e con cognizione altri utenti piu esperti....

    detto questo... fare tanti backend in rete credo sia contrario al principio stesso di avere un backend e tanti frontend....quindi da scartare...

    per la modifica dei record simultanei sicuramente dovrai guardare le opzioni di blocco record...

    ti incollo il link del sito ufficiale...



    spero di esserti d'aiuto
    ad maiora
  • Re: Back-end su SharePoint: performances accessi concorrenti?

    La scelta di access non è esattamente la prima che mi sarebbe venuta in mente in questo caso.
    Una quindicina di utenti mi sembrano parecchi.
    Miei suggerimenti per ordine
    1) cerca soluzione gratuita già fatta
    2) rifare da capo
    3) pagare qualcuno che ve la faccia con un minimo di 'grazia'
  • Re: Back-end su SharePoint: performances accessi concorrenti?

    CicciusPrime ha scritto:


    per la modifica dei record simultanei sicuramente dovrai guardare le opzioni di blocco record...
    Ma in realtà è praticamente impossibile che vi siano modifiche simultanee allo stesso record da più utenti, in quanto ognuno vede solo i propri dati. Per esempio c'è una sezione "Visite" dove ogni utente inserisce record relativi alle visite effettuate dai propri clienti e, vede solo i propri di record, in quanto l'origine dati della maschera di inserimento è una query parametrica.

    +m2+ ha scritto:


    La scelta di access non è esattamente la prima che mi sarebbe venuta in mente in questo caso.
    Una quindicina di utenti mi sembrano parecchi.
    Miei suggerimenti per ordine
    1) cerca soluzione gratuita già fatta
    2) rifare da capo
    3) pagare qualcuno che ve la faccia con un minimo di 'grazia'
    Guarda, mi trovi più che d'accordo.

    Il problema è che gli ordini mi sono arrivati dall'alto e io non ho potuto fare altro che eseguire. Adesso di fronte a queste problematiche mi tocca mettere insieme i pezzi e cercare di far funzionare tutto al meglio che si può.

    Ad ogni modo, l'applicazione funzionerebbe bene se non fosse per i problemi di velocità. Addirittura avevo provato a condividere via rete il file del database NON DIVISO e, dopo essermi loggato come admin (avendo accesso ai record degli altri), vedevo i record che inserivano gli altri in tempo reale. Peccato che in quel frangente fosse lento come l'anno della fame, decisamente non adatto ad un uso professionale.

    Se SharePoint mi risolvesse il problema velocità io sarei apposto, è per quello che mi interessava avere riscontri da qualcuno che magari lo ha già utilizzato.
  • Re: Back-end su SharePoint: performances accessi concorrenti?

    Candy91 ha scritto:


    ...
    Ad ogni modo, l'applicazione funzionerebbe bene se non fosse per i problemi di velocità.
    ...
    Se SharePoint mi risolvesse il problema velocità ...
    Precisazioni iniziali, che metteri in grassetto: non conosco SharePoint se non per "sentito dire" e per sommi capi e non sono il più ferrato in materia di accesso concorrente, autorizzazioni, annessi e connessi. In ogni caso dico la mia perché credo ci sia una questione "di fondo" da non trascurare.
    SharePoint funziona "in rete". Se già usare il db in rete (immagino LAN) era di fatto uno strazio per lentezza, sulla stessa rete non vedo come si possa trarre beneficio da SharePoint (ricordando che non l'ho mai usato però... a naso mi sento di dirlo lo stesso)
    A rischio di scrivere in un altro modo quanto già evidenziato da +m2+
    1) il db è fatto male e quindi non ci sono sistemi che tengano per farlo andar veloce (quindi bisogna rifare tutto, bene, o correggere quanto c'è di sbagliato. Chi fa questo? non ho suggerimenti diversi da quelli di +m2+)
    2) la rete è lenta di suo: o si capisce se c'è qualcosa di strano che la rallenta o si "cambia la rete"
    3) se non è né la 1) né la 2)... mettersi il cuore in pace.
    Io punterei molto sulla 1, con tutto il rispetto per chi ha lavorato su quel db.
  • Re: Back-end su SharePoint: performances accessi concorrenti?

    Philcattivocarattere ha scritto:


    SharePoint funziona "in rete". Se già usare il db in rete (immagino LAN) era di fatto uno strazio per lentezza, sulla stessa rete non vedo come si possa trarre beneficio da SharePoint (ricordando che non l'ho mai usato però... a naso mi sento di dirlo lo stesso)
    Perché, IN TEORIA, il server su cui si basa SharePoint dovrebbe essere molto più performante di una rete LAN, quindi in grado di permettere accessi contemporanei agli elenchi più velocemente.

    Correggimi se sbaglio. Per lo meno è quello che ho letto in siti/forum esteri.. Però le informazioni che son riuscito a trovare sono piuttosto fumose.

    Comunque grazie per i suggerimenti
  • Re: Back-end su SharePoint: performances accessi concorrenti?

    Candy91 ha scritto:


    Perché, IN TEORIA, il server su cui si basa SharePoint dovrebbe essere molto più performante di una rete LAN...
    Dipende tutto da dove si trova il problema della lentezza:
    1) dalla rete in senso stretto, magari una LAN molto datata, studiata male o studiata per un numero di postazioni molto inferiore rispetto a quelle ora collegate, dove il "traffico" è molto intenso. In questo caso per quanto il server sia potente (in calcolo) sempre sulla stessa rete è.
    2) dal computer su cui avevi salvato il database in LAN. Beh, in questo caso non è tanto il fatto di server-sharepoint-annessi e connessi ma di avere un computer decente.
    3) dalla somma del punto 1 e 2.

    Quello che intendo sottolineare è che bisogna indagare bene sui motivi della lentezza prima di pensare ad un "server-sharepoint-annessi e connessi" come
    la soluzione di tutto. Di certo un sistema studiato per lavorare in "multiutenza" parte già avvantaggiato rispetto ad Access (rigorosamente diviso in FE e BE) ma ci sono altre cose, da quello che dici, che meritano di essere analizzare, per avere la situazione completa, il quadro completo e con quello prendere la decisione giusta.
Devi accedere o registrarti per scrivere nel forum
6 risposte