Hello
Out of curiosity, is there a way to avoid putting calls to MySQL in
pages, and have PHP fetch data from a common pool, so that all
connected users don't actually call MySQL directly, but simply read
data from that common pool?
Just an idea. I don't know if it makes any sense :-)
Thanks.
not too meaningful, as the database is the common pool. If the idea is to
pool most recent data, so that subsequent calls put lighter pressure on db,
then I sure hope mysql does that itself.
you can opt to have some middle man there, but then you lost all the benefit
that the db gives you. the cost benefit is real problem.
Gilles Ganault wrote:
> Hello
>
> Out of curiosity, is there a way to avoid putting calls to MySQL in
> pages, and have PHP fetch data from a common pool, so that all
> connected users don't actually call MySQL directly, but simply read
> data from that common pool?
>
> Just an idea. I don't know if it makes any sense :-)
>
> Thanks.
I guess you're thinking about a cache concept, you should read some articles
about it; this can indeed be very useful if the database is submerged by
loads of identical, heavy search requests.
-thib´
On Sun, 13 Jan 2008 19:08:42 GMT, "Peter Pei"
wrote:
>you can opt to have some middle man there, but then you lost all the benefit
>that the db gives you. the cost benefit is real problem.
OK. So high-performance PHP applications are also sprinkled with calls
to MySQL, just like my newbie pages?
So, if I want higher perfs, and supposing that the MySQL part is
optimized as much as it can, the only option is to get a faster
server?
On Sun, 13 Jan 2008 20:33:59 +0100, thib´
wrote:
>I guess you're thinking about a cache concept, you should read some articles
>about it; this can indeed be very useful if the database is submerged by
>loads of identical, heavy search requests.
OK, I'll do some tests and see how it goes, even by keeping actually
MYSQL calls in all the pages. Thanks.
Gilles Ganault wrote:
> On Sun, 13 Jan 2008 19:08:42 GMT, "Peter Pei"
> wrote:
>> you can opt to have some middle man there, but then you lost all the benefit
>> that the db gives you. the cost benefit is real problem.
>
> OK. So high-performance PHP applications are also sprinkled with calls
> to MySQL, just like my newbie pages?
>
Sure, all over the place.
> So, if I want higher perfs, and supposing that the MySQL part is
> optimized as much as it can, the only option is to get a faster
> server?
>
Yes, but I find in most systems MySQL is not optimized as much as possible.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
On Sun, 13 Jan 2008 15:09:45 -0500, Jerry Stuckle
>Sure, all over the place.
I'd love to see some actual before/after code to see the impact on the
different ways to build CRUD apps in LAMP.
>Yes, but I find in most systems MySQL is not optimized as much as possible.
Where do they most often fail?
Gilles Ganault wrote:
> On Sun, 13 Jan 2008 20:33:59 +0100, thib´
> wrote:
>> I guess you're thinking about a cache concept, you should read some articles
>> about it; this can indeed be very useful if the database is submerged by
>> loads of identical, heavy search requests.
>
> OK, I'll do some tests and see how it goes, even by keeping actually
> MYSQL calls in all the pages. Thanks.
MySQL has a cache of its own... mysql_query_cache... search the mysql
website. And then there are caches like APC (Alternative PHP Cache) for PHP.
--
Norman
Registered Linux user #461062
On Sun, 13 Jan 2008 15:41:18 -0500, Norman Peelman
> MySQL has a cache of its own... mysql_query_cache... search the mysql
>website. And then there are caches like APC (Alternative PHP Cache) for PHP.
Thanks.
Gilles Ganault wrote:
> On Sun, 13 Jan 2008 15:09:45 -0500, Jerry Stuckle
>
>> Sure, all over the place.
>
> I'd love to see some actual before/after code to see the impact on the
> different ways to build CRUD apps in LAMP.
>
>> Yes, but I find in most systems MySQL is not optimized as much as possible.
>
> Where do they most often fail?
>
Lots of places. Anywhere from improper normalization to incorrect
indexes to poor MySQL optimization.
It takes time and effort to properly optimize MySQL - just like with any
other RDBMS.
--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex@attglobal.net
==================
> Out of curiosity, is there a way to avoid putting calls to MySQL in
> pages, and have PHP fetch data from a common pool, so that all
> connected users don't actually call MySQL directly, but simply read
> data from that common pool?
>
> Just an idea. I don't know if it makes any sense :-)
Possibility 1: You always need the same data. Then you can cache the pages.
Possibility 2: You need different data every time. Then what makes you think
the a crappy script language can provide them better than a dedicated db
engine?
I made the experience, that beyond all mysql optimisation and stuff, the
most common failure is to underestimate the db engine.
On Jan 13, 11:54 am, Gilles Ganault
> Hello
>
> Out of curiosity, is there a way to avoid putting calls to MySQL in
> pages, and have PHP fetch data from a common pool, so that all
> connected users don't actually call MySQL directly, but simply read
> data from that common pool?
>
> Just an idea. I don't know if it makes any sense :-)
>
> Thanks.
My 2 bits: optimizing your queries so as to make the least number of
calls to your DB while pulling back the most compact amount of info
possible is definitely something to check for. When I was a computing
science TA, every so often I'd see the horror of people making a
database call inside of a loop :) Another one was making separate
pulls from several tables for related data, instead of using a join
and so pulling just once.
Tyler
On Mon, 14 Jan 2008 05:22:06 -0800 (PST), tyler.style.post@gmail.com
wrote:
>My 2 bits: optimizing your queries so as to make the least number of
>calls to your DB while pulling back the most compact amount of info
>possible is definitely something to check for.
Thanks for the tip. I guess I should really forget the simplistic
examples with the view pages sprinkled with calls to MySQL, and
investigate MVC-based frameworks like CakePHP or Smarty instead.
On Mon, 14 Jan 2008 11:37:08 +0100, Jonas Werres
wrote:
>I made the experience, that beyond all mysql optimisation and stuff, the
>most common failure is to underestimate the db engine.
Good to know. Thanks.
Gilles Ganault wrote:
> On Mon, 14 Jan 2008 05:22:06 -0800 (PST), tyler.style.post@gmail.com
> wrote:
>> My 2 bits: optimizing your queries so as to make the least number of
>> calls to your DB while pulling back the most compact amount of info
>> possible is definitely something to check for.
>
> Thanks for the tip. I guess I should really forget the simplistic
> examples with the view pages sprinkled with calls to MySQL, and
> investigate MVC-based frameworks like CakePHP or Smarty instead.
Gilles,
I've not used Smarty or CakePHP, but I do use the template system
found here:
http://www.phpclasses.org/trackback/browse/package/54.html
....it's extremely fast and seems to do just what I need.
--
Norman
Registered Linux user #461062
On Mon, 14 Jan 2008 18:41:46 -0500, Norman Peelman
> I've not used Smarty or CakePHP, but I do use the template system
>found here:
>
>http://www.phpclasses.org/trackback/browse/package/54.html
Thanks. The URL is apparently:
http://www.phpclasses.org/browse/package/54.html
I'll give it a shot.
On Jan 13, 2:41 pm, Norman Peelman
> Gilles Ganault wrote:
> > On Sun, 13 Jan 2008 20:33:59 +0100, thib=B4
> > wrote:
> >> I guess you're thinking about a cache concept, you should read some art=
icles
> >> about it; this can indeed be very useful if the database is submerged b=
y
> >> loads of identical, heavy search requests.
>
> > OK, I'll do some tests and see how it goes, even by keeping actually
> > MYSQL calls in all the pages. Thanks.
>
> MySQL has a cache of its own... mysql_query_cache... search the mysql
> website. And then there are caches like APC (Alternative PHP Cache) for PH=
P.
>
> --
> Norman
> Registered Linux user #461062
And don't forget about 'memcache' - a mysql cache.