recursion or bad db request locking up browser

recursion or bad db request locking up browser

am 03.04.2008 12:30:25 von hedgomatic

I'm working on a complete rewrite of a now ancient word-association
program I use for writing ideas, song lyrics, etc.

I've written a simple database class I'm only using about two commands
out of at the moment, but I must be overlooking something already,
because the browser acts as if I've written something deeply or
infinitely recursive.

Database info - there are 3984 rows that include a word field that's
varchar 255, and an additional int 11 field for an ID that I never
used and defaults to 0. The word field is Indexed. The whole thing is
125kb.


Next we have index.php, manually requesting two words from the
database

include_once('idea.db.class.php');
getWord('2'); ?>


CLASS="element">'.$words[$i].'
'; } ?>


in idea.db.class.php, we have:
class dbConnect {

//some database variables here...

function dbConnect() {
$this->connection = @mysql_pconnect($this->server,$this->user,$this-
>password)or die($this->error2);
$this->dbSelect = mysql_select_db($this->database)or die ($this-
>error1);
}

function getWord($limit) {
$query = "SELECT word FROM $this->wordTable ORDER BY rand() LIMIT
$limit";
$result = mysql_query($query,$this->connection);
while ($data=mysql_fetch_array($result)) {
$word[] = $data['word'];
}
return $word;
}

// snip - other functions, etc
}
?>


This results in Firefox and IE both coughing and sputtering a bit
while returning the words, but usually we can get as far as seeing
them returned to the window. The browser status bar then suggests
however that it's still requesting data from the server, and maybe 5
seconds later it locks up permanently.


I've tried removing RAND(), I've obviously backed off the number of
requests to just two words, stripped everything else (javascript etc)
out of my index file...I'm stumped at what else it could be...the
pconnect? the default function in the class? Gremlins?

-Adam

Re: recursion or bad db request locking up browser

am 03.04.2008 12:36:52 von hedgomatic

has to be a recursion problem. Memory and CPU usage on the browser go
through the roof.

Re: recursion or bad db request locking up browser

am 03.04.2008 12:50:34 von Floortje

hedgomatic wrote:

> getWord('2'); ?>

>

> function getWord($limit) {
> while ($data=mysql_fetch_array($result)) {
> $word[] = $data['word'];
> }
> return $word;
> }

$word will contain an array so try

foreach($words as $word){}

or

for($i=0;$-
Arjen

Re: recursion or bad db request locking up browser

am 03.04.2008 12:52:22 von Dikkie Dik

>> for($i=0;$i<$words;$i++) { }

Try to see what happens if $words evaluates to 0 or less...

Best regards.

Re: recursion or bad db request locking up browser

am 03.04.2008 12:58:36 von hedgomatic

it's 7am and I doubt I'll get many responses, so why don't we make
this a lovely lil usenet example of how to solve your own %#&king
problem ;]

I've determined it's definitely the for() loop, which explains why it
feels like a recursion problem. Commenting that out the page loads
fine. But why? it's just a normal for loop....

first let's make sure there's nothing wrong with our array...

$words = Array('test','test2');
for($i=0;$i<$words;$i++) { echo '

CLASS="element">'.$words[$i].'
'; }

oof, and remembering i need count() in there helps a bit, ugh, it's
early...

$words = Array('test','test2');
for($i=0;$i CLASS="element">'.$words[$i].''; }

but somehow I'm still having a problem. wha?

well, trying this works. loads instantly--

for($i=0;$i //echo '
'.
$words[$i].'
';
echo 'test';
}

as does using a here doc instead:
for($i=0;$i echo <<
$words[$i]

END;
}

What? now I'm really confused. Why would a here doc work but not
single quotes? let's undo back to the single quotes and double-check
to verify that's still really a problem...

hmm. loaded fine that time, maybe the page hadn't finished uploading
when I hit the URL earlier. fair enough. Let's try slowly putting
everything back in...




getWord('2');

for($i=0;$i echo '
'.
$words[$i].'
';
}

ding!


Thanks usenet, I always feel better talking to you.

Re: recursion or bad db request locking up browser

am 03.04.2008 13:12:35 von Erwin Moller

hedgomatic schreef:
> it's 7am and I doubt I'll get many responses, so why don't we make
> this a lovely lil usenet example of how to solve your own %#&king
> problem ;]
>

Hedgomatic,

Why do you doubt you'll get many responses?
It is not 7 am in the rest of the world.
You must be from USA....

Regards,
Erwin Moller

Re: recursion or bad db request locking up browser

am 03.04.2008 13:48:36 von hedgomatic

It's not that I'm oblivious to the existence of other countries as
most Americans, some groups are just more frequented by GMT-5 and -8
than others. I didn't mean to imply you don't exist :]




On Apr 3, 7:12=A0am, Erwin Moller
wrote:
> hedgomatic schreef:
>
> > it's 7am and I doubt I'll get many responses, so why don't we make
> > this a lovely lil usenet example of how to solve your own %#&king
> > problem ;]
>
> Hedgomatic,
>
> Why do you doubt you'll get many responses?
> It is not 7 am in the rest of the world.
> You must be from USA....
>
> Regards,
> Erwin Moller

Re: recursion or bad db request locking up browser

am 03.04.2008 14:00:27 von hedgomatic

> $words is an array, not an integer. =A0You can use
> for($i=3D0;$i > or, better yet, foreach().

aye, lame mistake :]

I may need to enumerate, so I went with for().

that and I've always heard foreach() was slightly slower than for()
when iterating through arrays, because logically foreach doesn't know
its end until it gets there. foreach is supposed to be more readable,
but I've never really had a problem reading for()s. *shrug*

> error_reporting=3DE_ALL =A0// or E_ALL | E_STRICT)
> display_errors=3Don

my paid host understandably doesn't allow ini_set(). I should really
test stuff like this locally.

> Also, don't use persistent connections. =A0Unless you have a site running
> several hundred connections per second, it will hurt you more than it
> will help. =A0Just use mysql_connect().

eventually it probably will be a whole ton of connections. I'm
basically looking at a web version of something like wordpad, with the
ability to seed random words into the text. Difference being you
format whole words, not individual letters, and you can drag and drop
them around.

it depends on how many users, but I s'pose it's easy enough to swap
the letter p out till we need it.

Re: recursion or bad db request locking up browser

am 03.04.2008 14:17:08 von Jerry Stuckle

hedgomatic wrote:
> I'm working on a complete rewrite of a now ancient word-association
> program I use for writing ideas, song lyrics, etc.
>
> I've written a simple database class I'm only using about two commands
> out of at the moment, but I must be overlooking something already,
> because the browser acts as if I've written something deeply or
> infinitely recursive.
>
> Database info - there are 3984 rows that include a word field that's
> varchar 255, and an additional int 11 field for an ID that I never
> used and defaults to 0. The word field is Indexed. The whole thing is
> 125kb.
>
>
> Next we have index.php, manually requesting two words from the
> database
>
> include_once('idea.db.class.php');
> getWord('2'); ?>
>
>


> > CLASS="element">'.$words[$i].'
'; } ?>
>
>
> in idea.db.class.php, we have:
> > class dbConnect {
>
> //some database variables here...
>
> function dbConnect() {
> $this->connection = @mysql_pconnect($this->server,$this->user,$this-
>> password)or die($this->error2);
> $this->dbSelect = mysql_select_db($this->database)or die ($this-
>> error1);
> }
>
> function getWord($limit) {
> $query = "SELECT word FROM $this->wordTable ORDER BY rand() LIMIT
> $limit";
> $result = mysql_query($query,$this->connection);
> while ($data=mysql_fetch_array($result)) {
> $word[] = $data['word'];
> }
> return $word;
> }
>
> // snip - other functions, etc
> }
> ?>
>
>
> This results in Firefox and IE both coughing and sputtering a bit
> while returning the words, but usually we can get as far as seeing
> them returned to the window. The browser status bar then suggests
> however that it's still requesting data from the server, and maybe 5
> seconds later it locks up permanently.
>
>
> I've tried removing RAND(), I've obviously backed off the number of
> requests to just two words, stripped everything else (javascript etc)
> out of my index file...I'm stumped at what else it could be...the
> pconnect? the default function in the class? Gremlins?
>
> -Adam
>

As others mentioned -

for($i=0;$i<$words;$i++)

$words is an array, not an integer. You can use

for($i=0;$i
or, better yet, foreach().

If you had all errors being displayed, you should have gotten a notice
in your browser. In your development system's php.ini file you should
always have:

error_reporting=E_ALL // or E_ALL | E_STRICT)
display_errors=on

Also, don't use persistent connections. Unless you have a site running
several hundred connections per second, it will hurt you more than it
will help. Just use mysql_connect().

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: recursion or bad db request locking up browser

am 03.04.2008 17:10:49 von Jerry Stuckle

hedgomatic wrote:
>> $words is an array, not an integer. You can use
>> for($i=0;$i >> or, better yet, foreach().
>
> aye, lame mistake :]
>
> I may need to enumerate, so I went with for().
>

That's always a concern. But you can also get the index with foreach(),
i.e.

foreach($words as $key=>$word) {...

> that and I've always heard foreach() was slightly slower than for()
> when iterating through arrays, because logically foreach doesn't know
> its end until it gets there. foreach is supposed to be more readable,
> but I've never really had a problem reading for()s. *shrug*
>

The difference isn't noticeable. I actually prefer foreach(). I think
the code is cleaner.

>> error_reporting=E_ALL // or E_ALL | E_STRICT)
>> display_errors=on
>
> my paid host understandably doesn't allow ini_set(). I should really
> test stuff like this locally.
>

Yes, you always should have a local development system. Never develop
on a live site!

>> Also, don't use persistent connections. Unless you have a site running
>> several hundred connections per second, it will hurt you more than it
>> will help. Just use mysql_connect().
>
> eventually it probably will be a whole ton of connections. I'm
> basically looking at a web version of something like wordpad, with the
> ability to seed random words into the text. Difference being you
> format whole words, not individual letters, and you can drag and drop
> them around.
>
> it depends on how many users, but I s'pose it's easy enough to swap
> the letter p out till we need it.
>

But you aren't going to be running hundreds of connections per second -
that would be thousands of hits per second. And using mysql_pconnect()
can actually slow things the server down (and get your shared host
upset). With persistent connections, you must always have the maximum
number of connections you will ever need allocated. So if you hit a
bubble and need 100 connections at the same time, these 100 connections
must be allocated and will be taking system resources 24/7 - even if
your average is only 5 connections. They're even allocated when no one
is on your site.

Non-persistent connections are allocated on the fly. The overhead is
slightly more - but unless you have a remote database, the difference in
allocating the connection is minor.

There really should be more warnings in the doc about using persistent
connections and how bad they are.


--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: recursion or bad db request locking up browser

am 09.04.2008 07:26:25 von Sir Robin

On Thu, 03 Apr 2008 10:10:49 -0500, Jerry Stuckle
wrote:

>Yes, you always should have a local development system. Never develop
>on a live site!

You can - but you should do it on a subfolder with, for example, .htaccess
file that denyes access from all but allows your IP.

My local development system is also my public http server but I keep my
development stuff available only for "mr. 127.0.0.1".

--
***/--- Sir Robin (aka Jani Saksa) Bi-Sex and proud of it! ---\***
**/ email: robsku@fiveam.NO-SPAM.org, <*> Reg. Linux user #290577 \**
*| Me, Drugs, DooM, Photos, Writings... http://soul.fiveam.org/robsku |*
**\--- GSM/SMS: +358 44 927 3992 ---/**
"Kun nuorille opetetaan, että kannabis on yhtä vaarallista kuin heroiini,
niin tokihan he oppivat, että heroiini on yhtä vaaratonta kuin kannabis."

Re: recursion or bad db request locking up browser

am 09.04.2008 12:33:55 von Jerry Stuckle

Sir Robin wrote:
> On Thu, 03 Apr 2008 10:10:49 -0500, Jerry Stuckle
> wrote:
>
>> Yes, you always should have a local development system. Never develop
>> on a live site!
>
> You can - but you should do it on a subfolder with, for example, .htaccess
> file that denyes access from all but allows your IP.
>
> My local development system is also my public http server but I keep my
> development stuff available only for "mr. 127.0.0.1".
>

No. You should always have a separate development system.

For instance, not all of the PHP parameters can be set in .htaccess.
That's a minor concern; more of a concern is if you don something which
takes down the server. No, it *shouldn't* happen - but bugs in your
code and PHP working together can do it.

But the biggest reason is so you can duplicate the entire directory
structure, database, etc. on your development system. There is nothing
like having a problem when you go live because you accidentally had a
relative path wrong - or an absolute path pointing to the wrong
directory. Even worse is corrupting other files because you screwed up
something like move_uploaded_files(), unlink(), etc. And worse yet is
messing up your live database.

Too many things *can* go wrong. No, they may never do so. But the
purpose of a test system is to prevent problems like this from affecting
the live system. Using a directory on a live system for testing doesn't
do that, and is only slightly better than testing on the live system itself.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: recursion or bad db request locking up browser

am 10.04.2008 08:47:01 von hedgomatic

or you can just test in the exact place you mean to go live, because
it's just some personal project and nobody cares ;]



On Apr 9, 6:33=A0am, Jerry Stuckle wrote:
> Sir Robin wrote:
> > On Thu, 03 Apr 2008 10:10:49 -0500, Jerry Stuckle et>
> > wrote:
>
> >> Yes, you always should have a local development system. =A0Never develo=
p
> >> on a live site!
>
> > You can - but you should do it on a subfolder with, for example, .htacce=
ss
> > file that denyes access from all but allows your IP.
>
> > My local development system is also my public http server but I keep my
> > development stuff available only for "mr. 127.0.0.1".
>
> No. =A0You should always have a separate development system.
>
> For instance, not all of the PHP parameters can be set in .htaccess.
> That's a minor concern; more of a concern is if you don something which
> takes down the server. =A0No, it *shouldn't* happen - but bugs in your
> code and PHP working together can do it.
>
> But the biggest reason is so you can duplicate the entire directory
> structure, database, etc. on your development system. =A0There is nothing
> like having a problem when you go live because you accidentally had a
> relative path wrong - or an absolute path pointing to the wrong
> directory. =A0Even worse is corrupting other files because you screwed up
> something like move_uploaded_files(), unlink(), etc. =A0And worse yet is
> messing up your live database.
>
> Too many things *can* go wrong. =A0No, they may never do so. =A0But the
> purpose of a test system is to prevent problems like this from affecting
> the live system. =A0Using a directory on a live system for testing doesn't=

> do that, and is only slightly better than testing on the live system itsel=
f.
>
> --
> ==================
> Remove the "x" from my email address
> Jerry Stuckle
> JDS Computer Training Corp.
> jstuck...@attglobal.net
> ==================

Re: recursion or bad db request locking up browser

am 10.04.2008 23:16:56 von Jerry Stuckle

hedgomatic wrote:
>
>
> On Apr 9, 6:33 am, Jerry Stuckle wrote:
>> Sir Robin wrote:
>>> On Thu, 03 Apr 2008 10:10:49 -0500, Jerry Stuckle
>>> wrote:
>>>> Yes, you always should have a local development system. Never develop
>>>> on a live site!
>>> You can - but you should do it on a subfolder with, for example, .htaccess
>>> file that denyes access from all but allows your IP.
>>> My local development system is also my public http server but I keep my
>>> development stuff available only for "mr. 127.0.0.1".
>> No. You should always have a separate development system.
>>
>> For instance, not all of the PHP parameters can be set in .htaccess.
>> That's a minor concern; more of a concern is if you don something which
>> takes down the server. No, it *shouldn't* happen - but bugs in your
>> code and PHP working together can do it.
>>
>> But the biggest reason is so you can duplicate the entire directory
>> structure, database, etc. on your development system. There is nothing
>> like having a problem when you go live because you accidentally had a
>> relative path wrong - or an absolute path pointing to the wrong
>> directory. Even worse is corrupting other files because you screwed up
>> something like move_uploaded_files(), unlink(), etc. And worse yet is
>> messing up your live database.
>>
>> Too many things *can* go wrong. No, they may never do so. But the
>> purpose of a test system is to prevent problems like this from affecting
>> the live system. Using a directory on a live system for testing doesn't
>> do that, and is only slightly better than testing on the live system itself.
>>
> or you can just test in the exact place you mean to go live, because
> it's just some personal project and nobody cares ;]
>

(top posting fixed)

That's fine if it's your own site. But it's not a way a professional
should work.

P.S. Please don't top post. Thanks.



--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================

Re: recursion or bad db request locking up browser

am 13.04.2008 23:52:08 von Sir Robin

On Wed, 09 Apr 2008 06:33:55 -0400, Jerry Stuckle
wrote:

>Sir Robin wrote:
>> On Thu, 03 Apr 2008 10:10:49 -0500, Jerry Stuckle
>> wrote:
>>
>>> Yes, you always should have a local development system. Never develop
>>> on a live site!
>>
>> You can - but you should do it on a subfolder with, for example, .htaccess
>> file that denyes access from all but allows your IP.
>>
>> My local development system is also my public http server but I keep my
>> development stuff available only for "mr. 127.0.0.1".
>
>No. You should always have a separate development system.

I didn't mean to claim otherwise - yes, you should. But I for example don't
(yet) have one and I only meant to point that in such scenario you _can_ do
this - with various limitations, security concerns, need to pay more attention
to things (which has it good sides too). You can - unless the limitations of
doing it this way make it impossible - but if you have another way to do it
then you shouldn't - of course.

>For instance, not all of the PHP parameters can be set in .htaccess.
>That's a minor concern; more of a concern is if you don something which
>takes down the server. No, it *shouldn't* happen - but bugs in your
>code and PHP working together can do it.
>
>But the biggest reason is so you can duplicate the entire directory
>structure, database, etc. on your development system. There is nothing
>like having a problem when you go live because you accidentally had a
>relative path wrong - or an absolute path pointing to the wrong
>directory. Even worse is corrupting other files because you screwed up
>something like move_uploaded_files(), unlink(), etc. And worse yet is
>messing up your live database.
>
>Too many things *can* go wrong. No, they may never do so. But the
>purpose of a test system is to prevent problems like this from affecting
>the live system. Using a directory on a live system for testing doesn't
>do that, and is only slightly better than testing on the live system itself.

You make very good points here.

--
***/--- Sir Robin (aka Jani Saksa) Bi-Sex and proud of it! ---\***
**/ email: robsku@fiveam.NO-SPAM.org, <*> Reg. Linux user #290577 \**
*| Me, Drugs, DooM, Photos, Writings... http://soul.fiveam.org/robsku |*
**\--- GSM/SMS: +358 44 927 3992 ---/**
"I like the trees, you know? I like the way that the trees are on mountains,
all the different... the way the trees are."

Re: recursion or bad db request locking up browser

am 13.04.2008 23:55:47 von Sir Robin

On Thu, 10 Apr 2008 17:16:56 -0400, Jerry Stuckle
wrote:

>(top posting fixed)
>
>That's fine if it's your own site. But it's not a way a professional
>should work.

Indeed - good thing is that when your not doing something just as a hobby you
usually do have a development system available that you can use... When I
pointed out that you _can_ do it that way I forgot to say that you never
should do so unless you kind of have to... which is the case on my combined
server & desktop computer until I get at least one spare computer (with this
one running a virtual machine would not be a pleasant experience)

--
***/--- Sir Robin (aka Jani Saksa) Bi-Sex and proud of it! ---\***
**/ email: robsku@fiveam.NO-SPAM.org, <*> Reg. Linux user #290577 \**
*| Me, Drugs, DooM, Photos, Writings... http://soul.fiveam.org/robsku |*
**\--- GSM/SMS: +358 44 927 3992 ---/**
"Jokainen linkki, jonka päätteenä on ".org", on kelvoton tiedonlähde."
- Nikolas Mäki