abonnement Unibet Coolblue Bitvavo
  maandag 5 november 2012 @ 13:43:28 #241
91039 mstx
2x1/2 = 1/2 x 1/2
pi_118846190
quote:
0s.gif Op maandag 5 november 2012 13:32 schreef GlowMouse het volgende:
Kijk dan eens in apache's server-status of er clients verbonden blijven.
Ja bijna allemaal :P

Restart Time: Monday, 05-Nov-2012 13:07:20 CET
Parent Server Generation: 0
Server uptime: 30 minutes 42 seconds
Total accesses: 10271 - Total Traffic: 12.9 MB
CPU Usage: u1568.03 s77.94 cu0 cs0 - 89.4% CPU load
5.58 requests/sec - 7.2 kB/second - 1314 B/request
250 requests currently being processed, 0 idle workers

WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWWWWWWWKWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW
WWWWWWWWWWWWWWWWWWWWWWCWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWWW......

Na het restarten zie je alles langzaam in een W'tje veranderen totdat de max_connections van mysql bereikt is.
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  maandag 5 november 2012 @ 13:52:54 #242
75592 GlowMouse
l'état, c'est moi
pi_118846556
Dat is dan een groot probleem want elke W kost veel geheugen van Apache ook nog eens. Je kunt met extended server status nog preciezer zien wat elke W betekent.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_118847342
quote:
0s.gif Op zondag 4 november 2012 20:43 schreef pascal08 het volgende:
Wat is de juiste manier om URL's met CodeIgniter te rewriten in htaccess, zonder dat het pad naar m'n CSS-file wordt gerewrite waardoor m'n CSS-file niet correct geladen wordt?
Ik heb het nu zo:
<link rel="stylesheet" href="<?php echo base_url() ?>css/stylesheet.css" />

M'n htaccess file rewrite alles met index.php en zet m'n rootmap als base.

Precies wat ik wilde. ^O^
  maandag 5 november 2012 @ 21:56:31 #244
91039 mstx
2x1/2 = 1/2 x 1/2
pi_118869593
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen. :)
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel. :')
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt. _O-
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  maandag 5 november 2012 @ 22:10:43 #245
75592 GlowMouse
l'état, c'est moi
pi_118870434
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
  maandag 5 november 2012 @ 22:13:43 #246
91039 mstx
2x1/2 = 1/2 x 1/2
pi_118870588
quote:
0s.gif Op maandag 5 november 2012 22:10 schreef GlowMouse het volgende:
Pagina's deden er dus daadwerkelijk een halve minuut over om te laden, dat zou je sowieso snel door moeten hebben.
Ik had het al maanden zo draaien, kun je nagaan.
* mstx gaat zich diep schamen
Op donderdag 2 juli 2009 22:41 schreef RTB het volgende:
als ik elk rap"liedje" een kans moest geven was ik aan het eind van dit millennium nog bezig met het tempo waarin die kotshoop uitgebraakt wordt.
👾
  maandag 5 november 2012 @ 22:15:37 #247
75592 GlowMouse
l'état, c'est moi
pi_118870721
Zulke dingen kun je via een trace wel snel vinden waarschijnlijk. Htop en s/L zijn je vriend.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_118871339
ik weet dat ik hier fout zit maar zou iemand me aub kunnen zeggen hoe ik het volgende bestandje moet downloaden...na de 5sec blijf ik maar wachten

http://www.multiupload.nl/AKATNDA2Q0
Chuck Norris threw a grenade & killed 10 people. Then the grenade exploded.
  maandag 5 november 2012 @ 22:37:44 #249
75592 GlowMouse
l'état, c'est moi
pi_118871921
quote:
Dit bestand bestaat niet, de toegang tot het volgende bestand is beperkt of het bestand is verwijderd wegens overtreding van het auteursrecht.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_118881844
quote:
8s.gif Op maandag 5 november 2012 21:56 schreef mstx het volgende:
Nou ik ben er 5 uur mee bezig geweest, maar eindelijk gevonden waar die sleeping processes vandaan kwamen. :)
Het bleek te komen door de manier waarop ik user variables opsloeg in APC. Ik heb bijvoorbeeld nieuwsberichten of forum topics die ik met apc_store() opsloeg om te cachen. Eerst deed ik dit allemaal in één grote array met alle items erin (dus $forum=array(1=>'bericht1', 2=>'bericht 2'), $nieuws=array() etc). Nu heb ik ze allemaal hun eigen variabele gegeven. Nu is mijn script ineens 100x zo snel. :')
Nu ze allemaal apart staan hoeven ze niet meer op elkaar te wachten als 5 mensen tegenlijk 5 verschillende nieuwsberichten lezen en deze tegelijkertijd gecached worden, dan kan het script meteen verder en de mysql connectie sluiten... best stomme fout als je er zo achteraf over nadenkt. _O-
Nice dat het gefixt is! *O*

quote:
10s.gif Op maandag 5 november 2012 22:13 schreef mstx het volgende:

[..]

Ik had het al maanden zo draaien, kun je nagaan.
* mstx gaat zich diep schamen
:D

Heb je in de afgelopen maanden zo veel meer gebruikers gekregen dat het nu steeds erger werd?
gr gr
  dinsdag 6 november 2012 @ 21:05:03 #251
118011 BrainOverfloW
Fok! around the Clock!
pi_118906934
Hier meer mensen met een GitHub account en zo ja, kunnen jullie inloggen?
Ik heb me net aangemeld maar als ik in wil loggen blijft de site op de inlog pagina hangen of word ik terug gestuurd naar de homepage zonder ingelogd te zijn. Gebruikersnaam en wachtwoord pakt hij wel want ik krijg geen melding dat ik een fout heb gemaakt bij het intypen. Dus doe ik iets verkeerd of gaat er iets fout aan de kant van GitHub?
Whether or not you can become great at something, you can always become better.
And one day you'll wake up and find out how good you actually became, having transcended whatever limits you might have thought you couldn't pass.
Neil Degrasse Tyson
pi_118914532
quote:
0s.gif Op dinsdag 6 november 2012 21:05 schreef BrainOverfloW het volgende:
Hier meer mensen met een GitHub account en zo ja, kunnen jullie inloggen?
Ik heb me net aangemeld maar als ik in wil loggen blijft de site op de inlog pagina hangen of word ik terug gestuurd naar de homepage zonder ingelogd te zijn. Gebruikersnaam en wachtwoord pakt hij wel want ik krijg geen melding dat ik een fout heb gemaakt bij het intypen. Dus doe ik iets verkeerd of gaat er iets fout aan de kant van GitHub?
Ik kan gewoon inloggen.
pi_118920886
Ik heb nogal een lastig probleem. Ik weet niet wat de handigste manier is om letters met een accent in m'n database op te slaan, met betrekking op het volgende:

Momenteel is de í (i met accent acute) in de database opgeslagen als een Ã. Nu wil ik graag kunnen zoeken naar een woord met een í, zonder dat ik het accent erbij hoef te typen. Ik wil dus de í kunnen vinden door gewoon een i te typen.
  woensdag 7 november 2012 @ 01:32:40 #254
75592 GlowMouse
l'état, c'est moi
pi_118921155
Altijd voor UTF-8 kiezen, je kunt altijd een andere charset kiezen als je op zo'n rare i wilt zoeken.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
pi_118921387
quote:
0s.gif Op woensdag 7 november 2012 01:32 schreef GlowMouse het volgende:
Altijd voor UTF-8 kiezen, je kunt altijd een andere charset kiezen als je op zo'n rare i wilt zoeken.
Je bedoelt UTF-8 in m'n database toch? Ik gebruik nu latin1_swedish_ci:

Moet ik alles weer opnieuw in de database invoeren of veranderd 'ie alles "on-the-fly"?
pi_118921443
quote:
0s.gif Op woensdag 7 november 2012 01:44 schreef pascal08 het volgende:

[..]

Je bedoelt UTF-8 in m'n database toch? Ik gebruik nu latin1_swedish_ci: [ afbeelding ]

Moet ik alles weer opnieuw in de database invoeren of veranderd 'ie alles "on-the-fly"?
Ik heb het nu dus zo: , maar de í staat nog steeds als à in de database.
pi_118921510
Omdat het corrupt in je database is opgeslagen ;) Je kan niet zomaar terughalen wat je ooit bedoelde.
pi_118921527
quote:
0s.gif Op woensdag 7 november 2012 01:50 schreef StM het volgende:
Omdat het nu corrupt in je database is opgeslagen ;)
Dat vermoedde ik al, ik zal het dus opnieuw moeten invoeren. Moet ik nog iets als utf8_encode() gebruiken bij het invoeren?
pi_118921662
Je kan beter je hele app van UTF-8 gebruik laten maken. Juiste headers sturen etc.
pi_118921705
quote:
0s.gif Op woensdag 7 november 2012 01:58 schreef StM het volgende:
Je kan beter je hele app van UTF-8 gebruik laten maken. Juiste headers sturen etc.
Bedoel je zo?
pi_118921746
Ik persoonlijk geef de voorkeur aan
1
2
3
<?php
header
("Content-type: text/html; charset=utf-8");
?>
omdat dat soort meta tags als je ze verkeerd (te laat) gebruikt vooral bij oudere IE versies kan zorgen dat hij de pagina 2x moet parsen.

*edit*

Hier trouwens een handige checklist: http://blog.loftdigital.com/blog/php-utf-8-cheatsheet

edit2:

en vergeet
1
2
3
<?php
mysql_query
("SET NAMES 'utf8'")
?>
niet, via de adapter die jij gebruikt :) (Wss MySQLi of PDO)
pi_118921825
quote:
0s.gif Op woensdag 7 november 2012 02:03 schreef StM het volgende:
Ik persoonlijk geef de voorkeur aan
[ code verwijderd ]

omdat dat soort meta tags als je ze verkeerd (te laat) gebruikt vooral bij oudere IE versies kan zorgen dat hij de pagina 2x moet parsen.

*edit*

Hier trouwens een handige checklist: http://blog.loftdigital.com/blog/php-utf-8-cheatsheet

edit2:

en vergeet
[ code verwijderd ]

niet, via de adapter die jij gebruikt :) (Wss MySQLi of PDO)
Waar plaats ik die regel dan? Gewoon bovenaan m'n php script? Ik ben echt nog een newbie. :)
pi_118921836
Headers moet je versturen voor de eerste output. Dus ergens bovenaan of op een centrale plek.
pi_118921872
quote:
0s.gif Op woensdag 7 november 2012 02:09 schreef StM het volgende:
Headers moet je versturen voor de eerste output. Dus ergens bovenaan of op een centrale plek.
Gewoon bovenaan m'n header.php die elke pagina wordt geladen?

pi_118921894
Bv ja, hoewel je voor 1 regel code niet een aparte file hoeft aan te maken :) Wel kan je iets van een common.php aan maken die je altijd laad waar je dit maar ook andere defaults regelt.
pi_118921952
quote:
0s.gif Op woensdag 7 november 2012 02:13 schreef StM het volgende:
Bv ja, hoewel je voor 1 regel code niet een aparte file hoeft aan te maken :) Wel kan je iets van een common.php aan maken die je altijd laad waar je dit maar ook andere defaults regelt.
Ja, dat is dus header.php bij mij.

Hoe krijg ik nu bijvoorbeeld het woord "scène" op de goede manier in m'n database? Ik gebruik een PHP script om alles weg te schrijven.
pi_118921973
Die file ook als UTF-8 opslaan, vaak is dit een optie van je editor.
pi_118922013
quote:
0s.gif Op woensdag 7 november 2012 02:18 schreef StM het volgende:
Die file ook als UTF-8 opslaan, vaak is dit een optie van je editor.
Codering in m'n editor nu:


PHP-script dat de invoer regelt:


Output in m'n browser.


Wat er daadwerkelijk in de database wordt ingevoerd:



De output in m'n browser is dus hoe ik het in m'n database ingevoerd wil hebben. :@
pi_118922049
Heb je wel je verbinding op UTF-8 gezet zoals ik had gezegd? ;)
pi_118922072
quote:
0s.gif Op woensdag 7 november 2012 02:22 schreef StM het volgende:
Heb je wel je verbinding op UTF-8 gezet zoals ik had gezegd? ;)
Waar doe ik dat? :@
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')