* Uofficiel Black/White liste V3
|
Denne tråd er over 6 måneder gammel
Er du sikker på, at du har noget relevant at tilføje?
Søges: Database/PHP-haj til analyse af langsom hje...Af Ultra Supporter Jacob Mortensen | 08-01-2017 20:24 | 11374 visninger | 16 svar, hop til seneste
Hej,
Min kæreste har som sidegeschæft til sit arbejde, fået udviklet en mobilvenlig hjemmeside til en mindre virksomhed som digitaliserer nogle tidligere manuelle processer.
Selve udviklingen er sket af en 3. parts person som hun så har hyret til opgaven. Overordnet set er det gået rigtig godt, men desværre viser der sig nu performanceproblemer af hjemmesiden. Der er visse forespørgsler som bare tager riiiiigtig lang tid - så lang tid at brugere tror at siden er stoppet med at svare og lukker ned og starter forfra.
Korrespondancen går frem og tilbage med ham udvikleren, men det ligger lidt mellem linjerne at han ikke aner hvad han skal gøre ved problemet. Jeg er ikke interesseret i at snakke ansvarsplacering, men ønsker blot at tage et lidt andet take på denne problemstilling, da problemet efterhånden er ret akut da der er et stigende antal utilfredse brugere af hjemmesiden.
Det er ikke et særlig kompliceret stykke programmering der er lavet og siden er ikke særlig stor og der er derfor heller ikke mange tabeller. Ikke desto mindre er det stadig væsentligt mere kompliceret til at jeg kan løse udfordringen - jeg kan udelukkende PHP/SQL på hobbyplan.
Er der en som, mod betaling, har lyst til at tage et indledningsvist kig på databasen/programmellet sammen med mig over Skype/fjernskrivebord? I aller bedste fald kan du se det specifikke problem og udlede en løsning, men i første omgang håber jeg blot på at få en idé om hvor slemt det står til, og i hvilken retning løsningen skal findes.
Jeg tænker en timepris af 400,- og satser i første omgang på at skulle nøjes med at gøre brug af dig en times tid eller to. Jeg er ret sikker på at udfordringen ligger i selve databasedesignet, altså opbygningen af data/tabeller, så jeg har behov for at du kender en del til dette.
Mvh Jacob --
Hvilken database er det ? Gætter på mysql? Hvis du har et overblik over hvordan databasen er opbygget/hvor den har indexes, og så evt prøv at smide de sql queries som den bruger herind :) så er der måske gretis råd at hente
evt opret det i http://sqlfiddle.com[...] - uden nødvendigvis live data :) -- Gæstebruger, opret dit eget login og få din egen signatur. Jeg har tilføjet dig på Skype :) -- Hvis ikke Ide får dig i mål, så fang mig på
Thga detsjovea beknes punkt net
Thomas -- Udover den åbenlyse mulighed som du nævner med Database, er det måske værd at kigge på, om der kunne være et issue med stedet hvor siden er hostet.
Jeg har i hvert fald tidligere oplevet, at de billigere steder kan være noget "triste" i forhold til ydelse.
Ikke mindst når der er database inde over.
Jeg nævner det, fordi man skal fucke rimeligt meget op, hvis en side ligefrem skal stoppe med at svarer grundet database kald. Afhængig selvfølgelig af, hvordan databasen og ikke mindst queries er strukket sammen.
Du nævner selv, at det ikke er en videre kompliceret omgang kode der er lavet, så for mig lyder det som om, der er flere ting der skal undersøges. -- http://hamdentykke.dk[...] Stik mig adressen, eventuelt i en privat besked, så kan jeg lige lave en overflade analyse. -- Don't feed the trolls. --
Sidst redigeret 09-01-2017 09:10 Hvis det er en MySQL database der er tale om og du har mulighed for at rode med konfirugationen, så tag et kig på https://dev.mysql.com[...]
Det kan selvfølgelig også være selve PHP laget der er langsomt, en debug console (F12) i chrome/firefox med et kig på hvor lang tid requests tager i "network" tabben mens der surfes rundt på siden kan også give dig et billede af hvilke requests der er langsomme.
Hvis det er selve PHP delen der er langsom, så tag et kig på https://xdebug.org[...] - der kan du "optage" hvor lang tid hver enkel funktion tager og arbejde derudfra :)
Har eget firma og arbejder professionelt med API/web/applikations-udvikling - du er velkommen til at kontakte mig, smid en privat besked herinde. -- -- Hej med jer,
Hvor er det opløftende at så mange gerne vil forsøge at hjælpe - tak!
Jeg starter lige fra en ende og ser hvor langt #2 kan hjælpe mig via Skype, og hvis jeg får behov for yderligere, så vil jeg kontakte #3/#6.
#2 - jeg har godkendt dig på Skype.
Ang. hosting, så har jeg haft 2 kilder til at vurdere, at det er alt rigeligt der hvor siden kører nu. Vi flyttede netop fra Unoeuro af samme årsag, så nu er det hos en udbyder med lidt flere hestekræfter. Så det bør ikke være et problem, men kan af gode grunde ikke udelukke det 100%.
#6 - jeg kigger lige på dev.mysql (det er en mySQL-database, ja). Der er et mønster i, at nogle brugere oplever længere ventetid end andre afhængigt af hvor meget data der allerede ligger for den enkelte bruger. En nyoprettet bruger oplever ikke uhensigtsmæssig meget ventetid, så jeg tænker at det betyder at problemet ligger i databasen. -- #7
Hvis jeg tolker din tekst i #7 korrekt, så er det kun gamle brugere der oplever problemer?
Hvis det er tilfældet kan det være at der i database er noget indhold, der skaber konflikt ved afvikling.
Det kan også være at der er et/flere større loop som udfører uhensigtsmæssige mange åben/luk af databasen.
Hvis de andre i tråden ikke har løst til problemen, så kigger jeg gerne koden igennem.
(gratis selvfølgelig.) -- Jeg har tidligere optimeret systemer med lign symptomer med 5.000+ brugere, store databaser og meget tungt PHP,.
Ikke mindst udviklet fra bunden også.
Så du skal være velkommen til at kontakte mig.
Min mail står under profil. -- Indholdet af dette indlæg er blevet redigeret af NSA. Er du heldig, så kan lidt simpel indekserings optimering afhjælpe problemet.
Kan du ikke post din query log på pastebin.com og beskrive de relevante tabeller med describe http://dev.mysql.com[...] og post det også
Så kan vi holde hjælpen her i tråden på hol.dk, frem for via Skype og privat beskeder, så kan alle også læse med og til slut ender det måske ud i en løsning, hvilket igen måske vil gavne folk ude i fremtiden.
Giv en "dusør" til ham der finder problemet. -- Freelance PHP udvikler - Send PM for mine kontaktoplysninger. --
Sidst redigeret 09-01-2017 17:24 Jeg har set det omtalte kode og database, jeg ved slet ikke hvor jeg skal begynde, hvis jeg skal forklare det.. :) - Jeg vil jo helst heller ikke hænge udvikleren ud offentligt.... men...
Databasen er et godt mix af manglende index'er, store varchars hvor tinyint eller enum('yes','no') kunne benyttes, for slet ikke at nævne alle de rows der er effektive tomme, og kan slettes (ca. 2/3).
Et par underlige relationer i forsøg på at spare tabeller, fx. laaang varchar der indeholder en liste med id'er i en anden tabel, det gavner ikke performance.
Koden er plaget af alt for mange, redundante og unødvendige database kald, og et par misforståelser ang. grundlæggende programmering.
Jeg har smidt et par index'er og alter tables til #0 som instant boostede performance :) - Har også lavet et par omskrivninger af dele af koden, som jeg håber gavner ham... men der er lidt lang vej igen :( -- Indholdet af dette indlæg er blevet redigeret af NSA. #11
Det lyder ikke videre godt. En udvikler der har kastet sig over en opgave, som man reelt ikke havde forudsætninger for at udføre. -- http://hamdentykke.dk[...] #11 Hvordan så sikkerheden ud i koden, sådan ved første øjekast ?
Hvis der er så mange fundamentale fejl, så vil jeg mene at der er stor risiko for at der er sikkerhedshuller.
#0 Jeg mener du skal få fortaget en sikkerhedsanalyse af koden.
Jeg håber at de forbedringer, som#11 har lavet, kan skabe nok værdi til at "start forfra" med koden.
Det er nok det eneste rigtige at gøre på sigt.
-- Freelance PHP udvikler - Send PM for mine kontaktoplysninger. #11 Fedt med lidt opfølgning, altid interessant at høre lidt om problematikken!
#13 God pointe omkring sikkerheden, du har sikkert ret i at der eksistere sikkerhedshuller hvis koden i forvejen er lidt mangelfuld.
#0 Vi vil selvfølgelig gerne høre din opfølgning, og evt. ros/ris til TommyB, i tilfælde af at andre skulle have lignede behov for assistance. -- SQL injections er der fint sikret imod, faktisk er alle queries bygget op med prepared-statements.
Eneste lille sikkerheds detalje jeg kan pege på er en forkert implementering salt til passwords. Jeg vil ikke dele koden jer, men blot fortælle at pga. lidt PHP svipsere bliver passwords ikke salt'et. Men "kun" hashet x-antal gange med kendt algoritme.
Kodens mangler er udelukkende i dårlig databehandling og struktur, der er til gengæld også nok at tage fat på.
Jeg er ikke stødt på bagdøre eller killswitches :) -- Indholdet af dette indlæg er blevet redigeret af NSA. --
Sidst redigeret 15-01-2017 12:23 Ja som det fremgår af #11, så er der alligevel en del i vejen. Af samme årsag er jeg også meget glad for at have Tommy til at kigge dybdegående på det fremfor at have lagt det hele til skue her på tråden hvor man så hver især kunne byde ind med hjælp. Jeg havde behov for en straks-løsning, og den første ildebrand er slukket via de index'es som blev indsat. Nu er det så den fortsatte bæredygtighed af siden som skal sikres, men jeg har stor tiltro til at Tommy kan hjælpe mig derhen. Har indtil videre absolut ingen årsag til at tro andet, i hvert fald :-) --
Grundet øget spam aktivitet fra gæstebrugere, er det desværre ikke længere muligt, at oprette svar som gæst.
Hvis du ønsker at deltage i debatten, skal du oprette en brugerprofil.
Opret bruger | Login
|
Du skal være logget ind for at tilmelde dig nyhedsbrev.
Hvilken udbyder har du til internet? 425 personer har stemt - Mit energiselskab (Ewii f.eks) 12%
|
|
|