Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.php > #5827 > unrolled thread
| Started by | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| First post | 2012-05-06 11:12 +0200 |
| Last post | 2012-05-08 09:49 +0200 |
| Articles | 20 on this page of 143 — 18 participants |
Back to article view | Back to comp.lang.php
Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 11:12 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-06 11:51 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 17:23 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-06 18:11 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-07 20:05 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-07 20:23 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 17:16 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-07 16:49 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 15:01 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-07 20:15 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-07 20:37 -0700
Re: Windows binaries 64bit for PHP Arno Welzel <usenet@arnowelzel.de> - 2012-05-08 09:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-08 08:21 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-08 11:17 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:14 -0400
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 17:05 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:21 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-09 19:36 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-09 21:31 +0200
Re: Windows binaries 64bit for PHP Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2012-05-12 11:12 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:56 +0100
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:51 +0200
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 10:17 +0100
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-14 19:26 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:52 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:50 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:01 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:01 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:12 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:50 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 13:57 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:32 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 20:01 +0100
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-08 22:25 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-08 21:29 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 09:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:17 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 10:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-09 16:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 12:23 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 13:23 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 07:38 -0400
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-11 15:44 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:30 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-11 13:38 -0500
Re: Windows binaries 64bit for PHP Erwin Moller <erwinmollerusenet@xs4all.nl> - 2012-05-14 10:48 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-09 11:34 -0500
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 11:30 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 15:52 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 13:46 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 09:10 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 00:19 +0200
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-09 15:28 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 13:15 -0700
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-10 21:48 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 17:05 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 14:29 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 19:35 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-10 18:50 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 22:22 -0400
Re: Windows binaries 64bit for PHP Daniel Pitts <newsgroup.nospam@virtualinfinity.net> - 2012-05-11 10:03 -0700
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 13:56 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 11:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 06:51 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:11 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:29 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:11 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-12 01:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:44 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:36 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 14:01 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 10:34 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 20:58 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 15:30 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-11 21:46 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:14 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 14:42 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 11:04 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-12 18:40 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 15:49 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 22:59 +0100
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 13:46 +0200
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 07:50 -0500
Re: Windows binaries 64bit for PHP Anders Wegge Keller <wegge@wegge.dk> - 2012-05-13 16:15 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 10:36 -0400
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 09:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-13 18:54 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-13 13:27 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-13 22:26 -0500
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 09:51 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 08:04 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 14:25 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 09:37 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-14 16:22 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 16:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:07 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 22:37 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:47 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-14 16:53 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:06 -0400
Re: Windows binaries 64bit for PHP Shake <alex.estevezQUENO@QUENOfilnet.es> - 2012-05-14 20:36 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 14:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:04 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:48 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-14 23:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-14 17:57 -0400
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:38 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 20:46 -0400
Re: Windows binaries 64bit for PHP PlastiqueMAN <plastique@man.com> - 2012-05-23 22:45 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 00:18 -0400
Re: Windows binaries 64bit for PHP Stig Vestøl <stig@vestoldata.no> - 2012-05-24 11:40 +0200
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 12:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 09:12 -0400
Re: Windows binaries 64bit for PHP Shake <QUITAESTO@QUITAESTO.NOES> - 2012-05-24 16:29 +0200
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-24 20:41 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-24 15:17 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-11 21:53 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-11 18:15 -0400
Re: Windows binaries 64bit for PHP Luuk <luuk@invalid.lan> - 2012-05-12 10:00 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-12 07:29 -0400
Re: Windows binaries 64bit for PHP "Peter H. Coffin" <hellsop@ninehells.com> - 2012-05-12 06:47 -0500
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-12 00:40 +0100
Re: Windows binaries 64bit for PHP The Natural Philosopher <tnp@invalid.invalid> - 2012-05-11 01:07 +0100
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-09 23:53 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 08:49 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 08:02 -0400
Re: Windows binaries 64bit for PHP Michael Fesser <netizen@gmx.de> - 2012-05-10 21:09 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-10 15:32 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 17:56 +0200
Re: Windows binaries 64bit for PHP Jerry Stuckle <jstucklex@attglobal.net> - 2012-05-16 12:35 -0400
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-16 19:35 +0200
Re: Windows binaries 64bit for PHP Gregor Kofler <usenet@gregorkofler.com> - 2012-05-06 18:30 +0200
Re: Windows binaries 64bit for PHP Dominique Ottello <air.intakes@fra.fr.invalid> - 2012-05-06 19:04 +0200
Re: Windows binaries 64bit for PHP "J.O. Aho" <user@example.net> - 2012-05-12 16:45 +0200
Re: Windows binaries 64bit for PHP "Álvaro G. Vicario" <alvaro.NOSPAMTHANX@demogracia.com.invalid> - 2012-05-08 09:49 +0200
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-24 09:12 -0400 |
| Message-ID | <jplc4u$12c$1@dont-email.me> |
| In reply to | #6160 |
On 5/24/2012 6:00 AM, Shake wrote: > El 24/05/2012 11:40, Stig Vestøl escribió: >> >> That was the point i was trying to make. If performance is an issue, let >> apache serve the images. >> The overhead of using PHP to check if an image exists before sending it >> on every request is huge. > > There is no need to check every request. > > Check the process: > > Supose that the images are on the home of the image gallery: > > GET /Index.php -> served by PHP (by Apache) * > GET /scaleY/image1.png -> served by Apache (or LIGHTTP) ** > GET /scaleY/image2.png -> served by Apache (or LIGHTTP) ** > GET /scaleY/image3.png -> served by Apache (or LIGHTTP) ** > GET /scaleY/image4.png -> served by Apache (or LIGHTTP) ** > GET /scaleY/image5.png -> served by Apache (or LIGHTTP) ** > > * > Index.php check image files... If one of the images doesn't exists, it > generates. > If all images exists, no matters. Anyway PHP have to process index.php > so there is no overhead beyond a "if(file_exists))" in a foreach of images. > Right. Someone has to check on every request whether the image exists or not. In your case it is index.php. And although you think each test is a small overhead, it all adds up - very quickly. It's completely unnecessary if the images have been generated offline and uploaded. > ** > no PHP needed, images here had been always created. > > > Can anyone access to "/scaleY/image5.png" directly ? how? from where he > get the address? > > From google? (google have to had visited the index.php) Or other search > engine? (IDEM). > > Rgds. Sure they could. It's a URI, just like every other resource on the server. And there are any number of ways of getting the URI, especially if you're using a pattern to generate the file names. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <QUITAESTO@QUITAESTO.NOES> |
|---|---|
| Date | 2012-05-24 16:29 +0200 |
| Message-ID | <jplgl9$tfi$1@dont-email.me> |
| In reply to | #6163 |
NRN
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-24 20:41 +0200 |
| Message-ID | <e40tr75pln7tcq53lpesd7nhnsrq21c8en@mfesser.de> |
| In reply to | #6163 |
.oO(Jerry Stuckle) >On 5/24/2012 6:00 AM, Shake wrote: >> >> Index.php check image files... If one of the images doesn't exists, it >> generates. >> If all images exists, no matters. Anyway PHP have to process index.php >> so there is no overhead beyond a "if(file_exists))" in a foreach of images. >> > >Right. Someone has to check on every request whether the image exists >or not. And usually that's done by Apache itself for every single requested resource. If the resource is not there, it triggers a 404. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-24 15:17 -0400 |
| Message-ID | <jpm1g1$iap$1@dont-email.me> |
| In reply to | #6166 |
On 5/24/2012 2:41 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/24/2012 6:00 AM, Shake wrote: >>> >>> Index.php check image files... If one of the images doesn't exists, it >>> generates. >>> If all images exists, no matters. Anyway PHP have to process index.php >>> so there is no overhead beyond a "if(file_exists))" in a foreach of images. >>> >> >> Right. Someone has to check on every request whether the image exists >> or not. > > And usually that's done by Apache itself for every single requested > resource. If the resource is not there, it triggers a 404. > > Micha > Yup, and handling a 404 adds a significant amount of unnecessary overhead. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Luuk <luuk@invalid.lan> |
|---|---|
| Date | 2012-05-11 21:53 +0200 |
| Message-ID | <4a7089-sso.ln1@luuk.invalid.lan> |
| In reply to | #5976 |
On 11-05-2012 21:30, Jerry Stuckle wrote: > On 5/11/2012 2:58 PM, Shake wrote: >> Jerry Stuckle a couché sur son écran : >>> >>> Loading the script, starting the scripting module, initializing the >>> environment, interpreting and running the script, checking for the >>> presence of the image, storing a resized script if necessary, loading >>> the image and sending it, and cleaning up the environment. >>> >>> This vs. sending the image directly via an <img ...> tag. >>> >>> Nope, no extra overhead! And no way to send the image without a script! >>> >> >> The Extra overhead is something like in the code that generate the page: >> >> <?php >> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >> ?> >> >> Not look like an "application killer" to me. >> >> Greetings. >> >> > > There's a lot more to the overhead than that! > only when file does not exists, and, of course, the scaleImage wil make sure that it exists next time! So, there will only be some overhead 1 time ....
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-11 18:15 -0400 |
| Message-ID | <jok32k$hom$3@dont-email.me> |
| In reply to | #5979 |
On 5/11/2012 3:53 PM, Luuk wrote: > On 11-05-2012 21:30, Jerry Stuckle wrote: >> On 5/11/2012 2:58 PM, Shake wrote: >>> Jerry Stuckle a couché sur son écran : >>>> >>>> Loading the script, starting the scripting module, initializing the >>>> environment, interpreting and running the script, checking for the >>>> presence of the image, storing a resized script if necessary, loading >>>> the image and sending it, and cleaning up the environment. >>>> >>>> This vs. sending the image directly via an<img ...> tag. >>>> >>>> Nope, no extra overhead! And no way to send the image without a script! >>>> >>> >>> The Extra overhead is something like in the code that generate the page: >>> >>> <?php >>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >>> ?> >>> >>> Not look like an "application killer" to me. >>> >>> Greetings. >>> >>> >> >> There's a lot more to the overhead than that! >> > > only when file does not exists, > and, of course, the scaleImage wil make sure that it exists next time! > So, there will only be some overhead 1 time .... > One time for each image, vs. 0 times for each image if they are resized offline in a batch script. That overhead x 7.5 million images the op indicates he has is significant. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Luuk <luuk@invalid.lan> |
|---|---|
| Date | 2012-05-12 10:00 +0200 |
| Message-ID | <mth189-8q3.ln1@luuk.invalid.lan> |
| In reply to | #5982 |
On 12-05-2012 00:15, Jerry Stuckle wrote: > On 5/11/2012 3:53 PM, Luuk wrote: >> On 11-05-2012 21:30, Jerry Stuckle wrote: >>> On 5/11/2012 2:58 PM, Shake wrote: >>>> Jerry Stuckle a couché sur son écran : >>>>> >>>>> Loading the script, starting the scripting module, initializing the >>>>> environment, interpreting and running the script, checking for the >>>>> presence of the image, storing a resized script if necessary, loading >>>>> the image and sending it, and cleaning up the environment. >>>>> >>>>> This vs. sending the image directly via an<img ...> tag. >>>>> >>>>> Nope, no extra overhead! And no way to send the image without a >>>>> script! >>>>> >>>> >>>> The Extra overhead is something like in the code that generate the >>>> page: >>>> >>>> <?php >>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >>>> ?> >>>> >>>> Not look like an "application killer" to me. >>>> >>>> Greetings. >>>> >>>> >>> >>> There's a lot more to the overhead than that! >>> >> >> only when file does not exists, >> and, of course, the scaleImage wil make sure that it exists next time! >> So, there will only be some overhead 1 time .... >> > > One time for each image, vs. 0 times for each image if they are resized > offline in a batch script. > So, offline is for 'free' ? You are comparing apples with oranges here.... > That overhead x 7.5 million images the op indicates he has is significant. >
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-12 07:29 -0400 |
| Message-ID | <jolhj6$3ea$1@dont-email.me> |
| In reply to | #5990 |
On 5/12/2012 4:00 AM, Luuk wrote: > On 12-05-2012 00:15, Jerry Stuckle wrote: >> On 5/11/2012 3:53 PM, Luuk wrote: >>> On 11-05-2012 21:30, Jerry Stuckle wrote: >>>> On 5/11/2012 2:58 PM, Shake wrote: >>>>> Jerry Stuckle a couché sur son écran : >>>>>> >>>>>> Loading the script, starting the scripting module, initializing the >>>>>> environment, interpreting and running the script, checking for the >>>>>> presence of the image, storing a resized script if necessary, loading >>>>>> the image and sending it, and cleaning up the environment. >>>>>> >>>>>> This vs. sending the image directly via an<img ...> tag. >>>>>> >>>>>> Nope, no extra overhead! And no way to send the image without a >>>>>> script! >>>>>> >>>>> >>>>> The Extra overhead is something like in the code that generate the >>>>> page: >>>>> >>>>> <?php >>>>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >>>>> ?> >>>>> >>>>> Not look like an "application killer" to me. >>>>> >>>>> Greetings. >>>>> >>>>> >>>> >>>> There's a lot more to the overhead than that! >>>> >>> >>> only when file does not exists, >>> and, of course, the scaleImage wil make sure that it exists next time! >>> So, there will only be some overhead 1 time .... >>> >> >> One time for each image, vs. 0 times for each image if they are resized >> offline in a batch script. >> > > So, offline is for 'free' ? > You are comparing apples with oranges here.... > >> That overhead x 7.5 million images the op indicates he has is significant. >> > I never said offline is 'free'. But it can be done on any machine; it doesn't require taking response time from a live server. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | "Peter H. Coffin" <hellsop@ninehells.com> |
|---|---|
| Date | 2012-05-12 06:47 -0500 |
| Message-ID | <slrnjqsjet.4ci.hellsop@nibelheim.ninehells.com> |
| In reply to | #5990 |
On Sat, 12 May 2012 10:00:26 +0200, Luuk wrote:
> On 12-05-2012 00:15, Jerry Stuckle wrote:
>>
>> One time for each image, vs. 0 times for each image if they are resized
>> offline in a batch script.
>>
>
> So, offline is for 'free' ?
> You are comparing apples with oranges here....
offline *is* free from the standpoint of load on the frontline http
servers. Which should be top priority in considering how expensive
something is.
--
CANNIBAL, n.
A gastronome of the old school who preserves the simple tastes and
adheres to the natural diet of the pre-pork period.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 00:40 +0100 |
| Message-ID | <jok80o$8im$5@news.albasani.net> |
| In reply to | #5979 |
Luuk wrote: > On 11-05-2012 21:30, Jerry Stuckle wrote: >> On 5/11/2012 2:58 PM, Shake wrote: >>> Jerry Stuckle a couché sur son écran : >>>> Loading the script, starting the scripting module, initializing the >>>> environment, interpreting and running the script, checking for the >>>> presence of the image, storing a resized script if necessary, loading >>>> the image and sending it, and cleaning up the environment. >>>> >>>> This vs. sending the image directly via an <img ...> tag. >>>> >>>> Nope, no extra overhead! And no way to send the image without a script! >>>> >>> The Extra overhead is something like in the code that generate the page: >>> >>> <?php >>> if(!file_exists(IMG_PATH.$image_file)) scaleImage($image_file); >>> ?> >>> >>> Not look like an "application killer" to me. >>> >>> Greetings. >>> >>> >> There's a lot more to the overhead than that! >> > > only when file does not exists, > and, of course, the scaleImage wil make sure that it exists next time! > So, there will only be some overhead 1 time .... > exactly. Jerry is as usual talking out of his arse..he must have taken his head out. -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-11 01:07 +0100 |
| Message-ID | <johl7l$5d2$3@news.albasani.net> |
| In reply to | #5941 |
Daniel Pitts wrote: > On 5/10/12 2:05 PM, Jerry Stuckle wrote: >> On 5/10/2012 4:15 PM, Daniel Pitts wrote: >>> On 5/9/12 8:53 PM, Jerry Stuckle wrote: >>>> On 5/9/2012 6:28 PM, Daniel Pitts wrote: >>>>> On 5/9/12 3:19 PM, Michael Fesser wrote: >>>>>> .oO(Jerry Stuckle) >>>>>> >>>>>>> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>>>>>>> .oO(Jerry Stuckle) >>>>>>>> >>>>>>>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>>>>>>> Exactly true, but if you scale to sizes you don't need, you >>>>>>>>>> indeed >>>>>>>>>> use >>>>>>>>>> more processor time! Our disk space is definitely not the >>>>>>>>>> bottleneck. >>>>>>>>> >>>>>>>>> And if you repeatedly rescale the same image to the same size, >>>>>>>>> you're >>>>>>>>> using even more processor time! >>>>>>>> >>>>>>>> You missed the word 'caching'. You rescale when needed, and only >>>>>>>> once. >>>>>>> >>>>>>> No, I didn't. By definition, caching is temporary storage which >>>>>>> can be >>>>>>> erased at any time. >>>>>> >>>>>> Correct. And then the rescaled images are created again when >>>>>> needed, so >>>>>> what's the problem? It all happens automatically. >>>>>> >>>>>> Micha >>>>>> >>>>> >>>>> Caching needn't be temporary, and you can ensure it isn't "erased at >>>>> any >>>>> time" by just not erasing the "cache". There are many different >>>>> types of >>>>> "cache". >>>> >>>> By definition a cache is temporary. >>>> >>> Whose definition? >>> According to <http://www.thefreedictionary.com/cache> >>> >>> 1. "A collection of items of the same type stored in a hidden or >>> inaccessible place." >>> 2. Computer Science: A fast storage buffer in the central processing >>> unit of a computer. Also called cache memory. >>> >>> That doesn't define it as temporary. Perhaps you're mistaking your >>> understanding of the concept with reality. Reality wins over your >>> understanding. >>> >>> Anyway, I've had enough fun arguing with an obvious "expert" in this >>> field. Enjoy being "right" on the internet. >>> >>> Good day, >>> Daniel. >> >> And you obviously don't understand what you're reading. >> >> Since when is "memory" permanent? I thought that's why we had hard >> drives. And I don't see any thing in your definition about hard drives. >> > So, lets take a step back here. > > Forget the word caching, and your misunderstanding of it altogether. > > A system which will resize an image on-demand, and store the resize > image for later retrieval is more efficient ....IN CPU usage, but not disk storage.... >than one that will create > all known previous sizes and then reprocessing all old images as new > requirements are introduced. > > -- To people who know nothing, anything is possible. To people who know too much, it is a sad fact that they know how little is really possible - and how hard it is to achieve it.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-09 23:53 -0400 |
| Message-ID | <jofe39$iin$2@dont-email.me> |
| In reply to | #5899 |
On 5/9/2012 6:19 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/8/2012 4:25 PM, Michael Fesser wrote: >>> .oO(Jerry Stuckle) >>> >>>> On 5/7/2012 11:37 PM, Daniel Pitts wrote: >>>>> Exactly true, but if you scale to sizes you don't need, you indeed use >>>>> more processor time! Our disk space is definitely not the bottleneck. >>>> >>>> And if you repeatedly rescale the same image to the same size, you're >>>> using even more processor time! >>> >>> You missed the word 'caching'. You rescale when needed, and only once. >> >> No, I didn't. By definition, caching is temporary storage which can be >> erased at any time. > > Correct. And then the rescaled images are created again when needed, so > what's the problem? It all happens automatically. > > Micha > Repeatedly resizing the files is a huge waste of processor resources. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 08:49 +0200 |
| Message-ID | <o4pmq79lge2sebel3gg0k24s28tltgpvok@mfesser.de> |
| In reply to | #5906 |
.oO(Jerry Stuckle) >Repeatedly resizing the files is a huge waste of processor resources. Maybe you should get a decent machine? And "when needed" is not the same as "repeatedly". It's done _once_ and may only be repeated if someone would clear the image cache. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 08:02 -0400 |
| Message-ID | <jogaoc$r8j$2@dont-email.me> |
| In reply to | #5909 |
On 5/10/2012 2:49 AM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> Repeatedly resizing the files is a huge waste of processor resources. > > Maybe you should get a decent machine? And "when needed" is not the same > as "repeatedly". It's done _once_ and may only be repeated if someone > would clear the image cache. > > Micha > Yup. And a cache is by definition temporary - meaning that the images will have to be resized repeatedly. Or are you going to create a 1TB image cache? -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-10 21:09 +0200 |
| Message-ID | <n94oq71bgv2qh6vq9cls6oj6u7dpe8lqgf@mfesser.de> |
| In reply to | #5912 |
.oO(Jerry Stuckle) >Yup. And a cache is by definition temporary This could mean minutes, but also years. >meaning that the images >will have to be resized repeatedly. Only if someone intentionally deletes the cache. >Or are you going to create a 1TB image cache? If necessary, why not? Google caches almost its entire index of websites. But if you're so picky about definitions, don't call it an image cache, but "automated creation of static image resources". Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-10 15:32 -0400 |
| Message-ID | <joh53k$7t5$2@dont-email.me> |
| In reply to | #5932 |
On 5/10/2012 3:09 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> Yup. And a cache is by definition temporary > > This could mean minutes, but also years. > Yup, if you only get 200 hits a day it could be years. Active systems typically measure this in minutes at best. >> meaning that the images >> will have to be resized repeatedly. > > Only if someone intentionally deletes the cache. > Or the image is deleted from the cache to make more room, which is typically in seconds. >> Or are you going to create a 1TB image cache? > > If necessary, why not? Google caches almost its entire index of > websites. > Oh, so now you're writing systems as complicated as Google? ROFLMAO! > But if you're so picky about definitions, don't call it an image cache, > but "automated creation of static image resources". > > Micha > I'm using the term like it is defined. Just because you want to call a cow a horse doesn't make it a horse. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| Date | 2012-05-16 17:56 +0200 |
| Message-ID | <jri7r75444ii57dsk54fq5v28ugaffj735@4ax.com> |
| In reply to | #5838 |
Arno Welzel <usenet@arnowelzel.de> écrivait : > Ok - why do you need 64 bit at all for a web server? Tell me what you want, and I'll explain how you can not use it. This discussion has become a true troll. None of the 130 posts answered my question. Everyone has completely lost sight of the original question and digress on anything unrelated to the original subject. Ladies and gentlemen, goodbye, good luck and forever. -- La mort, c'est un peu comme la connerie. Le mort, lui, ne sait pas qu'il est mort, ce sont les autres qui sont tristes. Le con, c'est pareil. Signé : Le Chat.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-16 12:35 -0400 |
| Message-ID | <jp0l19$5vu$1@dont-email.me> |
| In reply to | #6082 |
On 5/16/2012 11:56 AM, Dominique Ottello wrote: > Arno Welzel<usenet@arnowelzel.de> écrivait : > >> Ok - why do you need 64 bit at all for a web server? > > Tell me what you want, and I'll explain how you can not use it. > > This discussion has become a true troll. > None of the 130 posts answered my question. Everyone has completely lost > sight of the original question and digress on anything unrelated to the > original subject. > Ladies and gentlemen, goodbye, good luck and forever. Dominique, Sorry, but that's how usenet goes sometimes. I think the biggest problem here is you're asking the wrong people. We're all just users of PHP; we don't develop PHP itself. So we really have no control over what Zend creates or doesn't create. But basically, Zend just creates the source files. It's up to the different OS distributions to create binaries; for instance, I use Debian and the Debian developers have created binaries (I can also create my own if I wish). Microsoft isn't going to create binaries, so it's up to some user to go to the trouble of getting the code to build on Windows. It obviously can be done, but it's not real easy (I've tried it in the past). So I'm not surprised someone hasn't stepped up and created a 64 bit Windows binary. But then that's what J.O. indicated in his first response to you. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Dominique Ottello <air.intakes@fra.fr.invalid> |
|---|---|
| Date | 2012-05-16 19:35 +0200 |
| Message-ID | <h6p7r7h32fhhe00opikkisjfe3m81o2krl@4ax.com> |
| In reply to | #6084 |
Jerry Stuckle <jstucklex@attglobal.net> écrivait : > Microsoft isn't going to create binaries, so it's up to some user to go > to the trouble of getting the code to build on Windows. It obviously > can be done, but it's not real easy (I've tried it in the past). So I'm > not surprised someone hasn't stepped up and created a 64 bit Windows binary. Thanks. Anindya does : http://www.anindya.com/php-5-4-3-and-php-5-3-13-x64-64-bit-for-windows/
[toc] | [prev] | [next] | [standalone]
| From | Gregor Kofler <usenet@gregorkofler.com> |
|---|---|
| Date | 2012-05-06 18:30 +0200 |
| Message-ID | <jo68v0$pc2$1@dont-email.me> |
| In reply to | #5829 |
Am 2012-05-06 17:23, Dominique Ottello meinte: > "J.O. Aho"<user@example.net> écrivait : > >>> PHP does not do it! >>> Why? Could it be that complicated to compile for 32 AND 64 bit? Perhaps not. But supposedly there is not enough demand for a 64 bit PHP in the Windows world. Or they don't want to spend money on a compiler. Ask them. >> Why don't Microsoft do it? All the Linuxes and Unixes does that. > This is a typical response of Linux user who brings strictly no > explanation to my question. I'm also a Linux chauvinist, however, I can turn to a search engine and g**gle "windows php 5.4 64bit" and choose the second hit: <http://www.anindya.com/php-5-4-0-x64-64-bit-for-windows/> That was easy, wasn't it? Gregor -- http://vxweb.net
[toc] | [prev] | [next] | [standalone]
Page 7 of 8 — ← Prev page 1 2 3 4 5 6 [7] 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web