abonnement bol.com Unibet Coolblue
  vrijdag 24 juni 2011 @ 16:25:29 #201
75592 GlowMouse
l'état, c'est moi
pi_98611940
quote:
0s.gif Op vrijdag 24 juni 2011 16:24 schreef ursel het volgende:

[..]

Dus als je een forum software aanraad moet ik hier gaan kijken zeg je?
Zoek nog steeds de meest optimale :+
Ja, al heb ik geen idee wat de echte versie kost.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98611989
quote:
0s.gif Op vrijdag 24 juni 2011 16:24 schreef GlowMouse het volgende:
Je zult InnoDB wel verkeerd hebben ingesteld.
Naar mijn weten niet, en op internet lees ik ook niet dat het echt een voordeel heeft (voor phpBB dan)
💍 💍 💍 💍 💍 💍 🍌 ☎
  vrijdag 24 juni 2011 @ 16:41:10 #203
75592 GlowMouse
l'état, c'est moi
pi_98612774
quote:
0s.gif Op vrijdag 24 juni 2011 16:26 schreef Pizzalucht het volgende:

[..]

Naar mijn weten niet, en op internet lees ik ook niet dat het echt een voordeel heeft (voor phpBB dan)
Tekenend voor de kennis van MySQL binnen het phpBB-team. Alleen ivm data-integriteit moet je MyISAM al links laten liggen, al zal InnoDB ook wel sneller zijn. Niet de snelheid waar je op hoopt overigens, want daarvoor zul je meer moeten meten.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98612979
quote:
14s.gif Op vrijdag 24 juni 2011 16:41 schreef GlowMouse het volgende:

[..]

Tekenend voor de kennis van MySQL binnen het phpBB-team. Alleen ivm data-integriteit moet je MyISAM al links laten liggen, al zal InnoDB ook wel sneller zijn. Niet de snelheid waar je op hoopt overigens, want daarvoor zul je meer moeten meten.
Het gaat me niet om de snelheid, meer om de load(die volgens mij te hoog is). De site zelf is al snel genoeg.

Time spent on mysql4 queries: 0.00889s | Time spent on PHP: 0.03169s

Query time is 0.4 bij een sessie update, en dit lijkt me te lang, of ligt dat aan mij?
💍 💍 💍 💍 💍 💍 🍌 ☎
  vrijdag 24 juni 2011 @ 16:48:24 #205
75592 GlowMouse
l'état, c'est moi
pi_98613101
Dat is zeker lang, dus dat is weldegelijk langzaam. Maar je moet meten waar die load vandaan komt. Het is puur giswerk te stellen dat vertraagd indices bijwerken zoals InnoDB doet, of row based locking dat deels kan verhelpen.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98613385
Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
sda 21.06 456.41 681.43 3145042988 4695641736
sdb 20.87 457.02 679.68 3149300549 4683635344

Dat is wat iostat geeft, ik weet niet echt wat ik er mee moet.

Timing buffered disk reads: 348 MB in 3.01 seconds = 115.80 MB/sec

Ik denk dat de load van de sessions updates komt, in een table van 500.000 rows.
💍 💍 💍 💍 💍 💍 🍌 ☎
  vrijdag 24 juni 2011 @ 16:55:35 #207
75592 GlowMouse
l'état, c'est moi
pi_98613443
doe eens:
iostat -dx 1
tijdens een drukke periode.

Wat voor query hoort daarbij en wat is de tabeldefinitie?
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98613704
Daar kom ik vanavond op terug, drukke periode is rond 10 uur.

Mijn fout. De 0.4s is niet bij een sessie update maar als de cache voor last topics etc is verlopen.

Daar kan de load dus niet vandaan komen, ik zal vanavond even kijken hoelang een session update query duurt.
💍 💍 💍 💍 💍 💍 🍌 ☎
  vrijdag 24 juni 2011 @ 17:06:16 #209
75592 GlowMouse
l'état, c'est moi
pi_98613936
Een cache miss is dus duur, dat is dan een groot probleem.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98617037
quote:
0s.gif Op vrijdag 24 juni 2011 17:06 schreef GlowMouse het volgende:
Een cache miss is dus duur, dat is dan een groot probleem.
Een cache mis komt echter bijna niet voor.
💍 💍 💍 💍 💍 💍 🍌 ☎
  vrijdag 24 juni 2011 @ 18:27:34 #211
75592 GlowMouse
l'état, c'est moi
pi_98617124
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98618202
quote:
Ik snap je punt, maar we hadden eerst geen cache op die query(en dus deed elke frontpage view 0.4s aan query), en toen hadden we die load ook.
💍 💍 💍 💍 💍 💍 🍌 ☎
pi_98620271
Een extra tabel gebruiken om counts in op te slaan, is dat een oplossing? Stel, mijn forum Model heeft naast een eigen tabel ook de beschikking over een count tabel die registreert hoeveel topics een bepaald sub forum heeft en dat model update automatisch de count tabel voor nieuwe/verwijderde topics. SELECT queries zijn immers goedkoper qua performance dan COUNT queries voor elke aanvraag van de forum index. Of kan ik COUNTs beter in-memory cachen?
  vrijdag 24 juni 2011 @ 19:55:12 #214
75592 GlowMouse
l'état, c'est moi
pi_98620376
Ik zou hem als kolom opnemen in je tabel met subforums. In memory cachen van rijen die je zo via primary key kunt ophalen loont niet.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_98670205
vraag me af kan je een deadlock met een functie A veroorzaken die aanroept naar een andere functie B die terugroept naar A? :) met een enkel proces? :P in PHP? zou dat uberhaupt mogelijk zijn is de vraag? zonder dat er een reader te pas komt.
Redacted
pi_98671055
quote:
0s.gif Op zondag 26 juni 2011 06:24 schreef cablegunmaster het volgende:
vraag me af kan je een deadlock met een functie A veroorzaken die aanroept naar een andere functie B die terugroept naar A? :) met een enkel proces? :P in PHP? zou dat uberhaupt mogelijk zijn is de vraag? zonder dat er een reader te pas komt.
Als je dat doet voert hij braaf uit wat je vraagt totdat max_execution_time bereikt is. PHP-proces zelf slaat niet op slot :)
  zondag 26 juni 2011 @ 10:03:45 #217
302853 themole
graaft totaal door.
pi_98671077
quote:
0s.gif Op zondag 26 juni 2011 06:24 schreef cablegunmaster het volgende:
vraag me af kan je een deadlock met een functie A veroorzaken die aanroept naar een andere functie B die terugroept naar A? :) met een enkel proces? :P in PHP? zou dat uberhaupt mogelijk zijn is de vraag? zonder dat er een reader te pas komt.
Nee dat gaat je pas lukken als je een multi-threaded proces gaat gebruiken. Dit kan hooguit een infinite loop veroorzaken. Een deadlock is als proces A wacht op proces B en proces B wacht op proces A om bijvoorbeeld een object te bewerken. :)
Niet altijd serieus
pi_98671097
quote:
0s.gif Op zondag 26 juni 2011 06:24 schreef cablegunmaster het volgende:
vraag me af kan je een deadlock met een functie A veroorzaken die aanroept naar een andere functie B die terugroept naar A? :) met een enkel proces? :P in PHP? zou dat uberhaupt mogelijk zijn is de vraag? zonder dat er een reader te pas komt.
quote:
0s.gif Op zondag 26 juni 2011 10:00 schreef Intrepidity het volgende:

[..]

Als je dat doet voert hij braaf uit wat je vraagt totdat max_execution_time bereikt is. PHP-proces zelf slaat niet op slot :)
Je hoeft echt geen 30 seconden (de standaard max_execution_time) te wachten. Probeer maar:
1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
function a()
{
    
b();
}

function 
b()
{
    
a();
}

a();
?>
pi_98694513
Waarom roep je in functie A niet gewoon weer A aan? :P
  woensdag 29 juni 2011 @ 16:49:40 #220
42636 TheSeeker_NL
Damn fine coffee
pi_98825285
Hey Fok!,

Ik ben begonnen met wat tutorials over PHP/MySQL en JQUERY, maar ik zit even vast omdat deze tutorials nogal los van elkaar staan.

Ik heb een database en een tabel met gegevens (nicknames). Deze nicknames worden geladen in een webpagina en in checkboxen geplaatst. Nu wil ik het volgende voor elkaar krijgen:

Na het selecteren van een aantal namen en het klikken op de knop verder wil ik deze informatie meenemen naar een volgende pagina en daar ze weer tonen. Dus gewoon een selectie meenemen naar een volgende pagina.

Ik hoef niet een exacte oplossing maar als jullie me kunnen vertellen in welke richting ik moet denken, dan ga ik zelf wel de betreffende informatie zoeken maar ik heb nu nog echt geen idee.
pi_98825809
quote:
0s.gif Op woensdag 29 juni 2011 16:49 schreef TheSeeker_NL het volgende:
Hey Fok!,

Ik ben begonnen met wat tutorials over PHP/MySQL en JQUERY, maar ik zit even vast omdat deze tutorials nogal los van elkaar staan.

Ik heb een database en een tabel met gegevens (nicknames). Deze nicknames worden geladen in een webpagina en in checkboxen geplaatst. Nu wil ik het volgende voor elkaar krijgen:

Na het selecteren van een aantal namen en het klikken op de knop verder wil ik deze informatie meenemen naar een volgende pagina en daar ze weer tonen. Dus gewoon een selectie meenemen naar een volgende pagina.

Ik hoef niet een exacte oplossing maar als jullie me kunnen vertellen in welke richting ik moet denken, dan ga ik zelf wel de betreffende informatie zoeken maar ik heb nu nog echt geen idee.
Ik zie niet zozeer in hoeverre je jQuery hierin denkt toe te passen, maar normaalgesproken stop je je checkboxes in een <form>-tag en kun je die in PHP aan de achterkant (na submit uiteraard) checken in de array $_POST. Wil je het met jQuery oplossen (asynchroon versturen en volgende pagina ophalen), dan kom je op methoden als $.ajax() of $.post() uit.
  woensdag 29 juni 2011 @ 17:41:44 #222
42636 TheSeeker_NL
Damn fine coffee
pi_98828036
quote:
0s.gif Op woensdag 29 juni 2011 16:59 schreef Intrepidity het volgende:

[..]

Ik zie niet zozeer in hoeverre je jQuery hierin denkt toe te passen, maar normaalgesproken stop je je checkboxes in een <form>-tag en kun je die in PHP aan de achterkant (na submit uiteraard) checken in de array $_POST. Wil je het met jQuery oplossen (asynchroon versturen en volgende pagina ophalen), dan kom je op methoden als $.ajax() of $.post() uit.
Sorry die informatie was misschien niet relevant, had ik er gewoon zonder na te denken bij gezet. Bedankt in elk geval alvast. Ik ga zo even inlezen :)
  woensdag 29 juni 2011 @ 23:26:48 #223
71610 Black-Hole
Deep in my soul
pi_98846566
Wie kan me op weg helpen met het volgende. Ben een mobiele versie aan het ontwikkelen van een website en uiteraard moeten mobiele browsers gedetecteerd worden. Prima werkend script voor gevonden alleen nu moet er ook een mogelijkheid zijn om weer terug te gaan van de mobiele site naar de reguliere website.

Volgens de ontwikkelaar van het script kan je deze loop stoppen met een action script. Heb zelf de ballen verstand van php maar wil dit wel leren. Wie kan me een beetje in de juiste richting helpen om dit aan te pakken?
pi_98846683
quote:
0s.gif Op woensdag 29 juni 2011 23:26 schreef Black-Hole het volgende:
Wie kan me op weg helpen met het volgende. Ben een mobiele versie aan het ontwikkelen van een website en uiteraard moeten mobiele browsers gedetecteerd worden. Prima werkend script voor gevonden alleen nu moet er ook een mogelijkheid zijn om weer terug te gaan van de mobiele site naar de reguliere website.

Volgens de ontwikkelaar van het script kan je deze loop stoppen met een action script. Heb zelf de ballen verstand van php maar wil dit wel leren. Wie kan me een beetje in de juiste richting helpen om dit aan te pakken?
Je zou eens kunnen beginnen met op een forum te vertellen wat je precies probeert en waar je op vast loopt zodat mensen je kunnen helpen.
pi_98847547
quote:
0s.gif Op woensdag 29 juni 2011 23:26 schreef Black-Hole het volgende:
Wie kan me op weg helpen met het volgende. Ben een mobiele versie aan het ontwikkelen van een website en uiteraard moeten mobiele browsers gedetecteerd worden. Prima werkend script voor gevonden alleen nu moet er ook een mogelijkheid zijn om weer terug te gaan van de mobiele site naar de reguliere website.

Volgens de ontwikkelaar van het script kan je deze loop stoppen met een action script. Heb zelf de ballen verstand van php maar wil dit wel leren. Wie kan me een beetje in de juiste richting helpen om dit aan te pakken?
Even een tip: tegenwoordig is het ook prima mogelijk om aparte stylesheets (of gedeelten ervan) toe te passen op kleinere schermen, waaronder die van mobieltjes. Kijk eens op deze website voor tal van goede voorbeelden van zogenaamde fluid layouts :) Die zijn de toekomst, aparte mobiele versies niet.
Resize deze website maar eens naar een paar 100 pixels breed bijvoorbeeld ;)
abonnement bol.com Unibet Coolblue
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')