abonnement Unibet Coolblue Bitvavo
  donderdag 2 maart 2006 @ 02:26:43 #211
12221 Tijn
Powered by MS Paint
pi_35631835
Wat is een beetje normale tijd waarin een script wordt uitgevoerd?

Of beter gezegd, als een script er langer dan hoeveel micro/milliseconden over doet, moet ik de boel nodig eens optimaliseren?
pi_35633236
quote:
Op donderdag 2 maart 2006 02:26 schreef Tijn het volgende:
Wat is een beetje normale tijd waarin een script wordt uitgevoerd?

Of beter gezegd, als een script er langer dan hoeveel micro/milliseconden over doet, moet ik de boel nodig eens optimaliseren?
helemaal afhankelijk van wat je doet...
als je allerlei moeilijke bewerkingen doet en 20 query's opent zal het script er langer over doen wannneer je alleen 1 query uitvoert
pi_35642446
ff domme vraag, maar waarom worden er in de bestandsnamen van includes de subextensie "inc" gebruikt. Dus dat je krijgt config.inc.php ipv. config.php .
Zitten daar meer voordelen aan dan alleen het kunnen herkennen van includes aan de bestandsnaam?
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 15:54:33 #214
1972 Swetsenegger
Egocentrische Narcist
pi_35644895
Aangezien ik opzoek ben naar een design, wil ik een design request topic openen. Het is niet de bedoeling dat daar hele website designs aangevraagd worden, maar bv een logootje of een button.

Maar...zoals ik maar matig kan designen, zullen er best designers zijn welke matig kunnen PHP'en. Dus denk ik erover om ook een centraal script request topic te openen. Is daar draagvlak voor onder de PHP'ers?
pi_35648013
quote:
Op donderdag 2 maart 2006 14:46 schreef blieblie het volgende:
ff domme vraag, maar waarom worden er in de bestandsnamen van includes de subextensie "inc" gebruikt. Dus dat je krijgt config.inc.php ipv. config.php .
Zitten daar meer voordelen aan dan alleen het kunnen herkennen van includes aan de bestandsnaam?
Nee.
pi_35648097
quote:
Op donderdag 2 maart 2006 02:26 schreef Tijn het volgende:
Wat is een beetje normale tijd waarin een script wordt uitgevoerd?

Of beter gezegd, als een script er langer dan hoeveel micro/milliseconden over doet, moet ik de boel nodig eens optimaliseren?
Dat hangt af van de machine waarop je script draait, de snelheid van de databaseserver waarmee je een verbinding hebt, en zo nog een paar honderd variabelen. Als je script bij normaal gebruik (geen zware zoekactie oid) merkbaar traag is (~ >100 ms) dan wordt het misschien tijd om uit te zoeken hoe dat komt.
  donderdag 2 maart 2006 @ 17:29:17 #217
12221 Tijn
Powered by MS Paint
pi_35648631
Ik snap dat het van vanalles afhangt, maar ik heb werkelijk geen idee wat "normaal" is. Ik heb een openingpagina gemaakt met 2 queries en wat for-lussen die zichzelf in 7 ms op het scherm zet. Ik vroeg me af of dat redelijk is. Maar ik begrijp dat je pas bij merkbare traagheid actie moet ondernemen en dat er geen algemene regel is in de trant van "als je pagina niet binnen 10 ms rendert is er wat mis" ofzo.
pi_35648785
quote:
Op donderdag 2 maart 2006 17:29 schreef Tijn het volgende:
Ik snap dat het van vanalles afhangt, maar ik heb werkelijk geen idee wat "normaal" is. Ik heb een openingpagina gemaakt met 2 queries en wat for-lussen die zichzelf in 7 ms op het scherm zet. Ik vroeg me af of dat redelijk is. Maar ik begrijp dat je pas bij merkbare traagheid actie moet ondernemen en dat er geen algemene regel is in de trant van "als je pagina niet binnen 10 ms rendert is er wat mis" ofzo.
Ben nog totaal niet thuis in PHP maar het lijkt mij dat dat soort dingen gewoon van de PC van de gebruiker afhangt? Op jouw AMD 3000+ zal het ws wel sneller dan 7ms zijn maar als je nog op een 1000+ draait...

Edit: Spuit 11
  donderdag 2 maart 2006 @ 17:34:37 #219
12221 Tijn
Powered by MS Paint
pi_35648828
quote:
Op donderdag 2 maart 2006 17:33 schreef DaFan het volgende:

[..]

Ben nog totaal niet thuis in PHP maar het lijkt mij dat dat soort dingen gewoon van de PC van de gebruiker afhangt? Op jouw AMD 3000+ zal het ws wel sneller dan 7ms duren maar als je nog op een 1000+ draait...
Nee. PHP draait op de server.
pi_35648879
Sorry Tijn ik zal me er niet meer mee bemoeien

Mijn vraag nogmaals:
quote:
Op woensdag 1 maart 2006 18:35 schreef DaFan het volgende:
Korte vraag, kheb de FAQs ed al doorgelezen en het idee is me duidelijk, maar ik krijg het niet aan de praat.
Het gaat om het áan de praat krijgen van MySQL functions in PHP 5 (Dit).

Nu heb ik gevolgd wat er allemaal staat, maar mysql_connect weigert te werken.

Voor de goede orde, mijn map waar php is geinstalleerd is:
1C:/php


php.ini staat in de WINDOWS map op de C:/schijf en daar zijn de volgende dingen gewijzigd:
1
2
extension_dir = "C:\php"
extension=php_mysql.dll     <- enabled


De libmysql.dll is toegevoegd én aan de Windows/system map en ik heb via de Omgevingsvariabelen C:/php als PATH aangegeven.

Kan iemand mij simpel en stap voor stap uitleggen wat er moet gebeuren binnen PHP 5 om MySQL functions aan de praat te krijgen?

Bedankt, en excuses dat ik er niet uitkom
Foutmelding die ik dus krijg is:
1Fatal error: Call to undefined function mysql_connect() in C:\Program Files\Apache Group\Apache2\htdocs\Forum\Do_addtopic.php on line 10


pi_35649555
@DaFan

Don't slap me with a trout, maar heb je de Apache webserver opnieuw gestart?
pi_35649744
quote:
Op donderdag 2 maart 2006 17:56 schreef JeRa het volgende:
@DaFan

Don't slap me with a trout, maar heb je de Apache webserver opnieuw gestart?
15x ongeveer
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 18:39:56 #223
1972 Swetsenegger
Egocentrische Narcist
pi_35651045
quote:
Op donderdag 2 maart 2006 18:02 schreef DaFan het volgende:

[..]

15x ongeveer
Waarom download je geen compleet pakket zoals bijvoorbeeld appserv? Dan hoef je niets te configureren. Installeren en draaien maar
pi_35651202
quote:
Op donderdag 2 maart 2006 18:39 schreef Swetsenegger het volgende:

[..]

Waarom download je geen compleet pakket zoals bijvoorbeeld appserv? Dan hoef je niets te configureren. Installeren en draaien maar
Heu das wel verdomde handig. Als je die installed werken ze dan direct met elkaar ? Dus PHP in Apache en MySQL zonder dat je ini's hoeft te verschuiven enzo?
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 18:44:15 #225
1972 Swetsenegger
Egocentrische Narcist
pi_35651230
quote:
Op donderdag 2 maart 2006 18:43 schreef DaFan het volgende:

[..]

Heu das wel verdomde handig. Als je die installed werken ze dan direct met elkaar ? Dus PHP in Apache en MySQL zonder dat je ini's hoeft te verschuiven enzo?
Ja
pi_35651263
Meesterlijk, vanavond eens proberen
  FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:01:35 #227
1972 Swetsenegger
Egocentrische Narcist
pi_35656214
Ik heb de volgende tabellen, waarbij cursieve kolommen FK's zijn (duh).

produkten:
  • product_id
  • article_code
  • name
  • etc

    users
  • user_id
  • name
  • address
  • etc

    orders
  • order_id
  • user_id
  • etc

    order_content
  • content_id
  • order_id
  • product_id
  • etc

    Meest gebruikte queries zijn niet zo spannend:
    1
    2
    3
    4
    5
    6
    <?php
    $query
    ="SELECT *
                   FROM produkten
                   WHERE product_menu="
    .$_GET['id']."  
                   ORDER BY first_price ASC, product_id DESC"
    ;
    ?>


    Immers ga je de tabellen pas aan elkaar koppelen na een bestelling, daarbij krijg je queries zoals deze:

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    <?php
    $query
    ="SELECT
            oc.number,
            p.articelcode,
            p.name,
            oc.giftwrap,
            p.first_price,
            p.second_price
            FROM orders o
            INNER JOIN order_content oc ON oc.order_id = o.order_id
            INNER JOIN produkten p ON p.product_id = oc.product_id
            INNER JOIN users u ON u.user_id = o.user_id
            WHERE o.order_id ="
    .$_GET['order']." && u.name='".$_SESSION['name']."'";
    ?>



    Eerste vraag:
    Hebben indices in deze situatie zin? De meeste queries zijn redelijk straight forward, alleen bij bestellingen wat gecompliceerder, maar die komen ook maar mondjesmaat voor.

    Tweede vraag:
    Laten we gemakshalve even aannemen dat indices relevant zijn, van welke kolommen moet ik dan indices maken om performance te winnen?

    Mijn boerenverstand zegt van alle FK's in alle tabellen dus orders.user_id, order_content.order_id en order_content.product_id.
    Maar... klopt dat wel? En kan iemand ook helder onder woorden brengen waarom?
  •   donderdag 2 maart 2006 @ 21:02:23 #228
    51748 H4ze
    wait...what?
    pi_35656247
    Ik zoek me een ongeluk, maar waar kan ik in godsnaam het maximale aantal connecties van mysql aanpassen? Op internet vind ik steeds /etc/my.cnf, maar ik ben geloof ik hardstikke blind....
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:03:44 #229
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656306
    quote:
    Op donderdag 2 maart 2006 21:02 schreef H4ze het volgende:
    Ik zoek me een ongeluk, maar waar kan ik in godsnaam het maximale aantal connecties van mysql aanpassen? Op internet vind ik steeds /etc/my.cnf, maar ik ben geloof ik hardstikke blind....
    php.ini?
      donderdag 2 maart 2006 @ 21:08:21 #230
    51748 H4ze
    wait...what?
    pi_35656471
    quote:
    Op donderdag 2 maart 2006 21:03 schreef Swetsenegger het volgende:

    [..]

    php.ini?
    Ik ben iets aan 't maken met mysql en JSP/Servlets, dus denk niet dat de php.ini er veel mee te maken heeft. Thnx voor 't snelle antwoord iig. Maar je moet toch gewoon via de mysql commandline iets kunnen opgeven?
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:11:09 #231
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656570
    quote:
    Op donderdag 2 maart 2006 21:08 schreef H4ze het volgende:

    [..]

    Ik ben iets aan 't maken met mysql en JSP/Servlets, dus denk niet dat de php.ini er veel mee te maken heeft. Thnx voor 't snelle antwoord iig. Maar je moet toch gewoon via de mysql commandline iets kunnen opgeven?
    Nee dan heeft php er niets mee te maken
    http://dev.mysql.com/doc/refman/4.1/en/too-many-connections.html Staat hier wat bij?
      donderdag 2 maart 2006 @ 21:12:59 #232
    51748 H4ze
    wait...what?
    pi_35656649
    quote:
    Op donderdag 2 maart 2006 21:11 schreef Swetsenegger het volgende:

    [..]

    Nee dan heeft php er niets mee te maken
    http://dev.mysql.com/doc/refman/4.1/en/too-many-connections.html Staat hier wat bij?
    jep al gelezen

    Stond in de reacties wel 1 iets bij:

    You can increase this value in main config file (e.g., /etc/my.cnf) using this syntax:

    [mysqld]
    set-variable=max_connections=250

    Dus ik heb in de commandline '--set-variable=max_connections=250'. Hij gaf dan geen error ofzo, maar ook niet dat het nu veranderd was....
    *BURP*
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:16:39 #233
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656781
    quote:
    Op donderdag 2 maart 2006 21:12 schreef H4ze het volgende:

    [..]

    jep al gelezen

    Stond in de reacties wel 1 iets bij:

    You can increase this value in main config file (e.g., /etc/my.cnf) using this syntax:

    [mysqld]
    set-variable=max_connections=250

    Dus ik heb in de commandline '--set-variable=max_connections=250'. Hij gaf dan geen error ofzo, maar ook niet dat het nu veranderd was....
    en als je my.cnf file gewoon opent?
    pi_35656843
    Leuk en aardig dat AppServ maar het werkt nog steeds niet. En nu kan ik totaal niet vinden waar ik in mn MySQL command kan komen. MySQLAdmin opent in DOS en is in 1 sec weer weg
    Dus nu kan ik helemaal niks meer
    pi_35656852
    Fuck it, morgen weer een dag.
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:20:18 #236
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35656922
    quote:
    Op donderdag 2 maart 2006 21:18 schreef DaFan het volgende:
    Leuk en aardig dat AppServ maar het werkt nog steeds niet. En nu kan ik totaal niet vinden waar ik in mn MySQL command kan komen. MySQLAdmin opent in DOS en is in 1 sec weer weg
    Dus nu kan ik helemaal niks meer
    Nou, dan weet ik niet wat je doet, want appserv is 3 keer next klikken, je files in de www directory zetten en openen met localhost/filename.php

    Meer valt er niet te configureren.
    Je hebt natuurlijk WEL eerste je voorgaande sql en php config gedelete.

    -edit- en wat ga je uberhaupt in MySQL command doen? Ga naar localhost/phpmyadmin.
    -edit2- Ow wacht, je moet een user aanmaken enzo http://www.phpfreakz.nl/artikelen.php?aid=62
    -edit3- Hoewel die standaard op root zonder password staat, en phpmyadmin daarmee moet kunnen verbinden.

    [ Bericht 5% gewijzigd door Swetsenegger op 02-03-2006 21:42:26 ]
      donderdag 2 maart 2006 @ 21:20:23 #237
    51748 H4ze
    wait...what?
    pi_35656926
    Ja ik was dus extreem scheef, kon die cnf file eerst niet vinden Krijg je van al de godganze dag zitten programmeren is nu opgelost

    Thnx iig
    *BURP*
    pi_35657513
    quote:
    Op donderdag 2 maart 2006 21:01 schreef Swetsenegger het volgende:
    Mijn boerenverstand zegt van alle FK's in alle tabellen dus orders.user_id, order_content.order_id en order_content.product_id.
    Maar... klopt dat wel? En kan iemand ook helder onder woorden brengen waarom?
    Eigenlijk alles waar op gefilterd of gesorteerd wordt. Dus de kolommen die in de join condities worden gebruikt, maar ook die in de where staan. Als er geen idex voor bestaat dan moet de hele tabel gescanned worden.
    Wil iedereen die in telekinese gelooft nu mijn hand op steken?
    | Foto's van toen en nu | Icons | Whatpulse keyboard | .NET developer? |
      FOK!-Schrikkelbaas donderdag 2 maart 2006 @ 21:41:43 #239
    1972 Swetsenegger
    Egocentrische Narcist
    pi_35657733
    quote:
    Op donderdag 2 maart 2006 21:36 schreef SuperRembo het volgende:

    [..]

    Eigenlijk alles waar op gefilterd of gesorteerd wordt. Dus de kolommen die in de join condities worden gebruikt, maar ook die in de where staan. Als er geen idex voor bestaat dan moet de hele tabel gescanned worden.
    Oke, dus als stelregel kan je zeggen dat je altijd(?) indices moet maken op foreign keys EN op kolommen welke (vaak) in where statements worden gebruikt, correct?

    Ik las namelijk op mysql.org dat het in sommige gevallen trager kan worden door indices.
    pi_35658279
    quote:
    Op donderdag 2 maart 2006 21:41 schreef Swetsenegger het volgende:

    [..]

    Oke, dus als stelregel kan je zeggen dat je altijd(?) indices moet maken op foreign keys EN op kolommen welke (vaak) in where statements worden gebruikt, correct?
    Niet bij álle foreign keys, maar het is een goede vuistregel ja. Voorbeeldje waarbij het niet moet; als je voor een fotoalbum drie groottes van een bepaalde foto hebt kun je die drie groottes in één record laten verwijzen naar drie foreign records, maar daar hoeft in principe helemaal geen index op omdat je daar nooit op selecteert of sorteert.
    quote:
    Ik las namelijk op mysql.org dat het in sommige gevallen trager kan worden door indices.
    In álle gevallen worden INSERTs trager door indices, en als het goed is kan MySQL zelf prima bepalen of het een index gebruikt of niet dus wat dat betreft zal het niet trager worden.
    abonnement Unibet Coolblue Bitvavo
    Forum Opties
    Forumhop:
    Hop naar:
    (afkorting, bv 'KLB')