"Dikkie Dik" <nospam@nospam.org> wrote in message
news:dmm8le$h1m$1@news.cistron.nl...
> Speaking about test: are you running the database, the webserver and the
> client on the same machine? In that case, you machine may be busy
> emulating network traffic AND performing the task.
>
I don't know about Stefan, but some developer's generally do this because
they don't have a budget adequate to have a dedicated machine for each
server they need to use. Others do this because they're part of a general
purpose network and can't take the chance of bogging down the network, and
thus impacting colleagues, while they're developing and testing code.

I run all the servers I need to work with on my development machine, and I
generally see response times from them that compare favourably relative to
any website I browse to during what little leasure time I may have. But
then, I generally insist on my development machine being the fastest I can
afford, loaded with loads of memory and hard disk space. That said, years
ago, I was doing the same thing on a mid range P-III and it handled the load
reasonably well. I am sure that once I deploy, all will run a little
faster, but then there is the network bottleneck to worry about.

In my experience, running several servers on an appropriate development
machine should not have the impact Stefan reported. Give the other posts,
esp. those testing his script (i.e. using it to insert 2000 records in 4
seconds using his script), either he has a configuration issue or his machne
is too slow for the job. I have seen nothing in this thread about the
machines used for the work. If the job is complete in 4 seconds on a dual
processor machine using dual core Athlon64 processors, and that machine is
fully loaded with RAM, and Stephan is using an ancient P-III with only a
little RAM and hard disk space, that difference in hardware might explain
the difference: all the hardware avaailable when the first P-III machines
came out were much much slower than that which can be obtained today. It is
impossible to say anything about why the script seems to be so slow without
knowing what hardware is being used and what else the system is doing,
except that the tests already reported in this thread exclude the script as
a culprit.

Alas, I can't offer additional insight into the cause of Stefan's problems
because I spend most of my time developing code, not administering servers.
I do not have the experience administering servers required to guess at how
a mistake configuring a server could cause Stefan's problems. I have
learned, the hard way and quite recently, how a mistake in programming
strategy can turn a job that should take minutes into a job that takes more
than a day, if it finishes at all. But Stefan's problem does not seem to be
a programming problem.

Cheers,

Ted

--
R.E. (Ted) Byers, Ph.D., Ed.D.
R & D Decision Support Solutions
http://www.randddecisionsupportsolutions.com/
Healthy Living Through Informed Decision Making