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 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 09:37 -0400 |
| Message-ID | <jor1qg$nnm$1@dont-email.me> |
| In reply to | #6025 |
On 5/14/2012 8:25 AM, Shake wrote: > El 14/05/2012 14:04, Jerry Stuckle escribió: >> >> You can do that when you have such a light load. Get a real load and >> you're in trouble. > > No. The EC2 machines does the image scaling and save the results on S3. > The thing is that first user getting the image will have to wait a > little more. That's true, but the server will not be overloaded. > Get a rteal load and you're in trouble. You'll be taking CPU time resizing images - EVERYONE will have to wait, not just one user. Get busy enough and you'll bring the server to its knees. > Ec2 could "grow" when necesary getting more CPU to "battle" the overload > without troubles. And cheapest than buying big machines to process > millions ob images offline, and then put online wasting a lot of traffic... > Or you can resize offline and not waste the server's resources. But that would take a bit of skill, I do understand. >> But even with that, you should be resizing offline and not requiring the >> server to do it. > > Not always possible, My way, first user, 2 second delay (in worst cases, > reescaling 4x3 images). Your way, all users three weeks of waiting. > It is always possible. First of all, you shouldn't be waiting until the website is complete before knowing what images you need to resize. Second, you really have no idea how long it takes you to resize YOUR images. You don't have 7.5M images - that was Daniel. And you have no idea what equipment he has. Third, if it does take 3 weeks to resize, then that's 3 weeks worth of load you're requiring the server to perform. That's what you don't get - the resizing takes time. > In real traffic, new images are scaled dilued inside normal traffic in > an unnoticeable wat. After putting on a new size.. next weeks or average > time per pages have no noticeable changes. > In REAL traffic your server won't have time to serve the web pages - it will be too busy resizing images. But your traffic is so light you don't see it. >> >> But it sounds like you're too cheap to get your developers decent >> machines, > > Me? I am a developer. Not the boss. And as a developer I don't need > powerfull machines able to reescale milions of images :) > No, but the graphics people should. And good companies give their developers good machines. And good companies know what shouldn't be done on servers. >> and have no idea how to scale images. The "nearest bigger >> scaled image" will almost certainly give a substandard image, especially >> when you repeatedly rescale them. > > Of course I know. I don't repeatedly scale all of them. You talk a lot > about things you don't know. I try to don't put every detail because I > though yoou can at least get the chance to believe that people have do > its work. > That was your statement. And I suspect that's what you really do - except this time you got caught at it. Nice try at back-pedaling. > How we scale images (at lest since a few months) > > Original size -> Big Size (watermarked if user wants) > Original size -> profile Size (Watermarked if user wants) > profile Size (previous to watermarking) -> Thumb_orig > profile Size (previous to watermarking) -> Thumb_size_2 > profile Size (previous to watermarking) -> Thumb_size_3 > > Thumb orig_ is the bigger thumbs we have. And new are always smaller. So > from this point we use thumb_orig to create new thumb sizes. Its of > course a second reescale, but for this little images is enought. And the > alternative was to use the original, that usually is a to big image. > Using an >5Mpixels image to generate a 100x70px (for example) image have > no sense. > > The "important" images are original, big and profile. The others are > just web little images. > > Greetings Gee, that's an awful lot of unnecessary work for the server. But I guess as long as you get so little traffic you can afford to do so. -- ================== 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-14 16:22 +0200 |
| Message-ID | <jor4ea$81f$1@dont-email.me> |
| In reply to | #6031 |
El 14/05/2012 15:37, Jerry Stuckle escribió: > Get a rteal load and you're in trouble. You'll be taking CPU time > resizing images - EVERYONE will have to wait, not just one user. Get > busy enough and you'll bring the server to its knees. ¿?¿? You read/understood something of what I wrote? [Balancer] [httpd] [httpd] [EC2] [Mysql*] [Sphinx*] [] independent systems. * And other services EC2 Machine does the scaling. Both balanced httpd are ready to process new incoming petitions. One of them have a process waiting answer from ec2 and only this one take more time to finish. the "HARD WORK" is done by auto-scalable EC2 machines. >> Ec2 could "grow" when necesary getting more CPU to "battle" the overload >> without troubles. And cheapest than buying big machines to process >> millions ob images offline, and then put online wasting a lot of >> traffic... > > Or you can resize offline and not waste the server's resources. But that > would take a bit of skill, I do understand. ¿?¿? What you say is the easy way. But ineffective. And waste resources, A LOT OF THEM. because implies having a few machines for a few days only doing this work! And also implies a few days without having this work available online! The images have to be resizes yes or yes. You thought that "the server" is only a http server. For me the server "do services". An the important services for the company where I get a lot of experience about big amount of image reescaling is having the images available for the user today, just 2 seconds after the click, and not two weeks in the future, just one second after the click. If you think that doing resize on server is risky. Yes, it is. You have to dimensionate correctly your hardware, and do a good logic. But it can be done, it's done everyday by a lot of companies. I worked in one of them. I saw. And I could empirecally (exists this word?) test the way you explain and the way I explain. And the result in the real world, is that the little overhead of this last is insignificant compared with the benefits. > >>> But even with that, you should be resizing offline and not requiring the >>> server to do it. >> >> Not always possible, My way, first user, 2 second delay (in worst cases, >> reescaling 4x3 images). Your way, all users three weeks of waiting. >> > > It is always possible. Is not if images sizes changes before you finished reescaling. > > First of all, you shouldn't be waiting until the website is complete > before knowing what images you need to resize. This say nothing. > Second, you really have no idea how long it takes you to resize YOUR > images. You don't have 7.5M images - that was Daniel. And you have no > idea what equipment he has. I don't know how long take Daniel's images. I know how long takes mine. I exposed mi case: 1million images. And post by post I have been detailing some data about the structure used to host. > > Third, if it does take 3 weeks to resize, then that's 3 weeks worth of > load you're requiring the server to perform. That's what you don't get - > the resizing takes time. You are mixing apples and oranges. It take 3 weeks to resize de images in computers that are not thinked to do. And buy a "good computer" only to scale off-line images is more expensive than using a good dimensioned server. >> In real traffic, new images are scaled dilued inside normal traffic in >> an unnoticeable wat. After putting on a new size.. next weeks or average >> time per pages have no noticeable changes. >> > In REAL traffic your server won't have time to serve the web pages - it > will be too busy resizing images. But your traffic is so light you don't > see it. But it is now working. On real world. And with traffic. Perhaps I do magic... and I am a wizard or you're wrong. > >>> >>> But it sounds like you're too cheap to get your developers decent >>> machines, >> >> Me? I am a developer. Not the boss. And as a developer I don't need >> powerfull machines able to reescale milions of images :) >> > > No, but the graphics people should. And good companies give their > developers good machines. And good companies know what shouldn't be done > on servers. The graphics people? what are you talking about? we are talking about rescaling images, not about its artistical content. And also we are not talking about good or bad companies. And I you think you have skills to judge about companies from a fragmented view you take from a few words on Usenet... Perhaps you are also a wizard like me... > > That was your statement. And I suspect that's what you really do - > except this time you got caught at it. Nice try at back-pedaling. I said what I said. And there is a lot of things I don't said. But you decided how I do what I don't said. If explaining about this is for you "back-pedaling" what are you trying to say? That I am lying or something like that? And... Why? :) have no sense. > Gee, that's an awful lot of unnecessary work for the server. But I guess > as long as you get so little traffic you can afford to do so. I wrote the traffic. 8 millions page views per month. And. Is work the server have to do! Because we serve images!!! And we serv today, not next week. Greetings
[toc] | [prev] | [next] | [standalone]
| From | Michael Fesser <netizen@gmx.de> |
|---|---|
| Date | 2012-05-14 16:45 +0200 |
| Message-ID | <pe62r7t8r4346ogt6r96a9i8il8kmbs70r@mfesser.de> |
| In reply to | #6034 |
.oO(Shake) >El 14/05/2012 15:37, Jerry Stuckle escribió: > >> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of >> load you're requiring the server to perform. That's what you don't get - >> the resizing takes time. > >You are mixing apples and oranges. It take 3 weeks to resize de images >in computers that are not thinked to do. And buy a "good computer" only >to scale off-line images is more expensive than using a good dimensioned >server. Additionally resizing offline would create a whole bunch of images that are hardly used, if ever, while doing it on-the-fly just creates what's really needed. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 14:07 -0400 |
| Message-ID | <jorhl0$tnv$2@dont-email.me> |
| In reply to | #6035 |
On 5/14/2012 10:45 AM, Michael Fesser wrote: > .oO(Shake) > >> El 14/05/2012 15:37, Jerry Stuckle escribió: >> >>> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of >>> load you're requiring the server to perform. That's what you don't get - >>> the resizing takes time. >> >> You are mixing apples and oranges. It take 3 weeks to resize de images >> in computers that are not thinked to do. And buy a "good computer" only >> to scale off-line images is more expensive than using a good dimensioned >> server. > > Additionally resizing offline would create a whole bunch of images that > are hardly used, if ever, while doing it on-the-fly just creates what's > really needed. > > Micha > Why would you resize an image if it's never needed? And if it's needed even ONCE resizing offline is better. -- ================== 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-14 22:37 +0200 |
| Message-ID | <q5r2r7d1ud5en9bqplsi5l3p55thor6kis@mfesser.de> |
| In reply to | #6042 |
.oO(Jerry Stuckle) >On 5/14/2012 10:45 AM, Michael Fesser wrote: > >> Additionally resizing offline would create a whole bunch of images that >> are hardly used, if ever, while doing it on-the-fly just creates what's >> really needed. > >Why would you resize an image if it's never needed? You don't know beforehand which images will really be requested by the visitors. Some of them may only be used once a month, if ever. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 17:47 -0400 |
| Message-ID | <joruie$haa$1@dont-email.me> |
| In reply to | #6049 |
On 5/14/2012 4:37 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/14/2012 10:45 AM, Michael Fesser wrote: >> >>> Additionally resizing offline would create a whole bunch of images that >>> are hardly used, if ever, while doing it on-the-fly just creates what's >>> really needed. >> >> Why would you resize an image if it's never needed? > > You don't know beforehand which images will really be requested by the > visitors. Some of them may only be used once a month, if ever. > > Micha > If you need it once a millenium, you need to resize it. And if you don't know what's needed on the site, you need to look more closely at your site. Sure, there may be products which will never be looked at - but how do you know who might want a $10,000 ping pong ball? Offline resizing is free as far as the server is concerned. And the server load is most important. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-14 16:53 +0100 |
| Message-ID | <jor9pa$gn9$1@news.albasani.net> |
| In reply to | #6034 |
Shake wrote: > El 14/05/2012 15:37, Jerry Stuckle escribió: >> Get a rteal load and you're in trouble. You'll be taking CPU time >> resizing images - EVERYONE will have to wait, not just one user. Get >> busy enough and you'll bring the server to its knees. > > ¿?¿? You read/understood something of what I wrote? No point in explaining anything to Stucklehead. He is by his own definition, always right. -- 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-14 14:06 -0400 |
| Message-ID | <jorhji$tnv$1@dont-email.me> |
| In reply to | #6034 |
On 5/14/2012 10:22 AM, Shake wrote: > El 14/05/2012 15:37, Jerry Stuckle escribió: >> Get a rteal load and you're in trouble. You'll be taking CPU time >> resizing images - EVERYONE will have to wait, not just one user. Get >> busy enough and you'll bring the server to its knees. > > ¿?¿? You read/understood something of what I wrote? > Yes, I understood EVERYTHING you said. > > [Balancer] > > [httpd] [httpd] [EC2] > > [Mysql*] [Sphinx*] > > [] independent systems. > * And other services > > EC2 Machine does the scaling. Both balanced httpd are ready to process > new incoming petitions. One of them have a process waiting answer from > ec2 and only this one take more time to finish. the "HARD WORK" is done > by auto-scalable EC2 machines. > Which actually means nothing. The server is still tied up resizing images, which means it can't do its real job (serving page requests). > > >>> Ec2 could "grow" when necesary getting more CPU to "battle" the overload >>> without troubles. And cheapest than buying big machines to process >>> millions ob images offline, and then put online wasting a lot of >>> traffic... >> >> Or you can resize offline and not waste the server's resources. But that >> would take a bit of skill, I do understand. > > ¿?¿? What you say is the easy way. But ineffective. And waste resources, > A LOT OF THEM. because implies having a few machines for a few days only > doing this work! And also implies a few days without having this work > available online! > It is a waste of SERVER resources to force the server to do it! And that is much more critical than workstation resources. > The images have to be resizes yes or yes. You thought that "the server" > is only a http server. For me the server "do services". An the important > services for the company where I get a lot of experience about big > amount of image reescaling is having the images available for the user > today, just 2 seconds after the click, and not two weeks in the future, > just one second after the click. > Web sites don't go online in 5 minutes. You should know well ahead of when the site goes "live" what resources are required, and plan to do the resizing. But I also understand that's not possible when you're flying by the seat of your pants. > If you think that doing resize on server is risky. Yes, it is. You have > to dimensionate correctly your hardware, and do a good logic. But it can > be done, it's done everyday by a lot of companies. I worked in one of > them. I saw. And I could empirecally (exists this word?) test the way > you explain and the way I explain. And the result in the real world, is > that the little overhead of this last is insignificant compared with the > benefits. > In the "real world", people don't do unnecessary work on the server. > >> >>>> But even with that, you should be resizing offline and not requiring >>>> the >>>> server to do it. >>> >>> Not always possible, My way, first user, 2 second delay (in worst cases, >>> reescaling 4x3 images). Your way, all users three weeks of waiting. >>> >> >> It is always possible. > > Is not if images sizes changes before you finished reescaling. > Sure, it is ALWAYS possible. But why would the image size change before rescaling? You should know ahead of time what you're going to need. It's called PLANNING, not flying by the seat of your pants. And BTW - it's not just one user waiting - it's EVERYONE. You're taking CPU resources, amongst other things, and there is a limit to what's available. What it being taken by resizing is not available to anyone else. Not a real problem when you have such a lightly loaded site as you do. But I can see why you need all that power to serve so few hits. >> >> First of all, you shouldn't be waiting until the website is complete >> before knowing what images you need to resize. > > This say nothing. > This is called PLANNING. > >> Second, you really have no idea how long it takes you to resize YOUR >> images. You don't have 7.5M images - that was Daniel. And you have no >> idea what equipment he has. > > I don't know how long take Daniel's images. I know how long takes mine. > I exposed mi case: 1million images. And post by post I have been > detailing some data about the structure used to host. > OK, 1M images should be done in a few hours on a decent machine, not the 3 weeks you claim. But you really have no idea how long it takes, do you? And if that fast of a server takes an extra 2 seconds to resize one image, you've got more problems than just the resizing. >> >> Third, if it does take 3 weeks to resize, then that's 3 weeks worth of >> load you're requiring the server to perform. That's what you don't get - >> the resizing takes time. > > You are mixing apples and oranges. It take 3 weeks to resize de images > in computers that are not thinked to do. And buy a "good computer" only > to scale off-line images is more expensive than using a good dimensioned > server. > No, I'm not mixing anything. And a good dimensioned server is MUCH MORE EXPENSIVE - both to purchase and to maintain - than one decent workstation. >>> In real traffic, new images are scaled dilued inside normal traffic in >>> an unnoticeable wat. After putting on a new size.. next weeks or average >>> time per pages have no noticeable changes. >>> >> In REAL traffic your server won't have time to serve the web pages - it >> will be too busy resizing images. But your traffic is so light you don't >> see it. > > But it is now working. On real world. And with traffic. Perhaps I do > magic... and I am a wizard or you're wrong. > 260K hits/day is not "traffic". But you're already showing the inefficiencies by needing that much power for that few hits. I do more than that on one of my VPS's, for instance. >> >>>> >>>> But it sounds like you're too cheap to get your developers decent >>>> machines, >>> >>> Me? I am a developer. Not the boss. And as a developer I don't need >>> powerfull machines able to reescale milions of images :) >>> >> >> No, but the graphics people should. And good companies give their >> developers good machines. And good companies know what shouldn't be done >> on servers. > > The graphics people? what are you talking about? we are talking about > rescaling images, not about its artistical content. > It is graphics, and is best handled by graphics people. That's the way major companies do it, for instance. > And also we are not talking about good or bad companies. And I you think > you have skills to judge about companies from a fragmented view you take > from a few words on Usenet... Perhaps you are also a wizard like me... > I can tell from what you told me about your operation. >> >> That was your statement. And I suspect that's what you really do - >> except this time you got caught at it. Nice try at back-pedaling. > > I said what I said. And there is a lot of things I don't said. But you > decided how I do what I don't said. > Yes, and if you didn't mean what you said, you shouldn't have said it. > If explaining about this is for you "back-pedaling" what are you trying > to say? That I am lying or something like that? > You're changing your story when you got caught. > And... Why? :) have no sense. > >> Gee, that's an awful lot of unnecessary work for the server. But I guess >> as long as you get so little traffic you can afford to do so. > > I wrote the traffic. 8 millions page views per month. And. Is work the > server have to do! Because we serve images!!! And we serv today, not > next week. > > Greetings Yes, 8M is a light load. But you need an awful lot of power to even handle that light load. Now I know why. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Shake <alex.estevezQUENO@QUENOfilnet.es> |
|---|---|
| Date | 2012-05-14 20:36 +0200 |
| Message-ID | <jorjc5$99c$1@dont-email.me> |
| In reply to | #6041 |
Après mûre réflexion, Jerry Stuckle a écrit : > > Yes, I understood EVERYTHING you said. Sure? >> [httpd] [httpd] [EC2] >> EC2 Machine does the scaling. > > Which actually means nothing. The server is still tied up resizing images, > which means it can't do its real job (serving page requests). The server that have to serve page request, is not resizing images. Perhaps, if someone ask you if you understood, the first thing you have to do if check if really you understood. And I finish here, because if obvious that if the habitual people of this group is not capable to dialogue with you, me and my poor english are totally out of any posibility to do. Greetings
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 14:53 -0400 |
| Message-ID | <jorkbh$f5h$1@dont-email.me> |
| In reply to | #6043 |
On 5/14/2012 2:36 PM, Shake wrote: > Après mûre réflexion, Jerry Stuckle a écrit : >> >> Yes, I understood EVERYTHING you said. > > Sure? > >>> [httpd] [httpd] [EC2] >>> EC2 Machine does the scaling. >> >> Which actually means nothing. The server is still tied up resizing >> images, which means it can't do its real job (serving page requests). > > The server that have to serve page request, is not resizing images. > Perhaps, if someone ask you if you understood, the first thing you have > to do if check if really you understood. > You have stated you have the server resizing the images. Now you're saying it's not. Which is it? > And I finish here, because if obvious that if the habitual people of > this group is not capable to dialogue with you, me and my poor english > are totally out of any posibility to do. > > Greetings > > It's not your ENGLISH which is making you incapable of understanding. -- ================== 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-14 23:04 +0200 |
| Message-ID | <vls2r7dpre03dlmdgf2vv5llldhusrn8f2@mfesser.de> |
| In reply to | #6045 |
.oO(Jerry Stuckle) >On 5/14/2012 2:36 PM, Shake wrote: >> Après mûre réflexion, Jerry Stuckle a écrit : >>> >>> Yes, I understood EVERYTHING you said. >> >> Sure? >> >>>> [httpd] [httpd] [EC2] >>>> EC2 Machine does the scaling. >>> >>> Which actually means nothing. The server is still tied up resizing >>> images, which means it can't do its real job (serving page requests). >> >> The server that have to serve page request, is not resizing images. >> Perhaps, if someone ask you if you understood, the first thing you have >> to do if check if really you understood. > >You have stated you have the server resizing the images. Now you're >saying it's not. Which is it? Obviously you didn't understand EVERYTHING he said. Might I suggest to read the thread again? Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 17:48 -0400 |
| Message-ID | <joruk4$haa$2@dont-email.me> |
| In reply to | #6051 |
On 5/14/2012 5:04 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/14/2012 2:36 PM, Shake wrote: >>> Après mûre réflexion, Jerry Stuckle a écrit : >>>> >>>> Yes, I understood EVERYTHING you said. >>> >>> Sure? >>> >>>>> [httpd] [httpd] [EC2] >>>>> EC2 Machine does the scaling. >>>> >>>> Which actually means nothing. The server is still tied up resizing >>>> images, which means it can't do its real job (serving page requests). >>> >>> The server that have to serve page request, is not resizing images. >>> Perhaps, if someone ask you if you understood, the first thing you have >>> to do if check if really you understood. >> >> You have stated you have the server resizing the images. Now you're >> saying it's not. Which is it? > > Obviously you didn't understand EVERYTHING he said. Might I suggest to > read the thread again? > > Micha > Yes, I did understand him, Micha. He has way more server than is required for his load, probably due to his poor coding techniques (loading the servers down with unnecessary work). -- ================== 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-14 23:00 +0200 |
| Message-ID | <nar2r7thbee1bvlntbq4shkcrh23nlefla@mfesser.de> |
| In reply to | #6041 |
.oO(Jerry Stuckle) >On 5/14/2012 10:22 AM, Shake wrote: > >> [Balancer] >> >> [httpd] [httpd] [EC2] >> >> [Mysql*] [Sphinx*] >> >> [] independent systems. >> * And other services >> >> EC2 Machine does the scaling. Both balanced httpd are ready to process >> new incoming petitions. One of them have a process waiting answer from >> ec2 and only this one take more time to finish. the "HARD WORK" is done >> by auto-scalable EC2 machines. > >Which actually means nothing. The server is still tied up resizing >images, which means it can't do its real job (serving page requests). Obviously a picture server doesn't serve pages. >> ¿?¿? What you say is the easy way. But ineffective. And waste resources, >> A LOT OF THEM. because implies having a few machines for a few days only >> doing this work! And also implies a few days without having this work >> available online! > >It is a waste of SERVER resources to force the server to do it! And >that is much more critical than workstation resources. How could a server waste resources by doing the job it is dedicated for? Does a database server waste resource by answering SQL requests? If there's a server (even a virtual one) dedicated to serve pictures in various formats, how could it waste resources by doing exactly that? >> The images have to be resizes yes or yes. You thought that "the server" >> is only a http server. For me the server "do services". An the important >> services for the company where I get a lot of experience about big >> amount of image reescaling is having the images available for the user >> today, just 2 seconds after the click, and not two weeks in the future, >> just one second after the click. > >Web sites don't go online in 5 minutes. You should know well ahead of >when the site goes "live" what resources are required, and plan to do >the resizing. But I also understand that's not possible when you're >flying by the seat of your pants. So you know beforehand which resources will actually be requested by your visitors? Do you also know the lottery numbers for next week? With a million images there's a good chance that a lot of them will hardly be requested, if ever. I consider it a waste of server and network resources to pre-calculate and upload all of them at once. If there's a picture server - let it do the work as necessary. >> If you think that doing resize on server is risky. Yes, it is. You have >> to dimensionate correctly your hardware, and do a good logic. But it can >> be done, it's done everyday by a lot of companies. I worked in one of >> them. I saw. And I could empirecally (exists this word?) test the way >> you explain and the way I explain. And the result in the real world, is >> that the little overhead of this last is insignificant compared with the >> benefits. > >In the "real world", people don't do unnecessary work on the server. Doesn't seem to happen here. Obviously the EC2 cloud does exactly what it is intended to do and paid for. >And BTW - it's not just one user waiting - it's EVERYONE. You're taking >CPU resources, amongst other things, and there is a limit to what's >available. What it being taken by resizing is not available to anyone else. In a cloud environment CPU power is the least problem. >Not a real problem when you have such a lightly loaded site as you do. >But I can see why you need all that power to serve so few hits. No paragraph of you without insults, directly or subtly. You can't live without that, right? >>> First of all, you shouldn't be waiting until the website is complete >>> before knowing what images you need to resize. >> >> This say nothing. > >This is called PLANNING. You can't plan your visitors. Micha -- http://mfesser.de/blickwinkel
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-14 17:57 -0400 |
| Message-ID | <jorv47$lfs$1@dont-email.me> |
| In reply to | #6050 |
On 5/14/2012 5:00 PM, Michael Fesser wrote: > .oO(Jerry Stuckle) > >> On 5/14/2012 10:22 AM, Shake wrote: >> >>> [Balancer] >>> >>> [httpd] [httpd] [EC2] >>> >>> [Mysql*] [Sphinx*] >>> >>> [] independent systems. >>> * And other services >>> >>> EC2 Machine does the scaling. Both balanced httpd are ready to process >>> new incoming petitions. One of them have a process waiting answer from >>> ec2 and only this one take more time to finish. the "HARD WORK" is done >>> by auto-scalable EC2 machines. >> >> Which actually means nothing. The server is still tied up resizing >> images, which means it can't do its real job (serving page requests). > > Obviously a picture server doesn't serve pages. > Nope, but resizing an image requires server resources which can be better spent elsewhere. >>> ¿?¿? What you say is the easy way. But ineffective. And waste resources, >>> A LOT OF THEM. because implies having a few machines for a few days only >>> doing this work! And also implies a few days without having this work >>> available online! >> >> It is a waste of SERVER resources to force the server to do it! And >> that is much more critical than workstation resources. > > How could a server waste resources by doing the job it is dedicated for? > Does a database server waste resource by answering SQL requests? If > there's a server (even a virtual one) dedicated to serve pictures in > various formats, how could it waste resources by doing exactly that? > The server is made for serving requests. Resizing images is not necessary for serving the request, if the correct image size has been uploaded already. Having to have a special server just to serve images in different sizes should tell you how much server load is being wasted! And your question about SQL is completely unrelated. I will ignore it. >>> The images have to be resizes yes or yes. You thought that "the server" >>> is only a http server. For me the server "do services". An the important >>> services for the company where I get a lot of experience about big >>> amount of image reescaling is having the images available for the user >>> today, just 2 seconds after the click, and not two weeks in the future, >>> just one second after the click. >> >> Web sites don't go online in 5 minutes. You should know well ahead of >> when the site goes "live" what resources are required, and plan to do >> the resizing. But I also understand that's not possible when you're >> flying by the seat of your pants. > > So you know beforehand which resources will actually be requested by > your visitors? Do you also know the lottery numbers for next week? > I know what sizes of images are going to be needed, where they are needed, and what I have to start with images. That's all I need to provide the correct size for all images. > With a million images there's a good chance that a lot of them will > hardly be requested, if ever. I consider it a waste of server and > network resources to pre-calculate and upload all of them at once. > If there's a picture server - let it do the work as necessary. > "hardly be requested" is not the same as "never needed". And uploading images is almost no load at all on a server; you could probably upload 10K pictures and not use as many server resources as resizing one image (ftp is VERY resource unintensive!). As for network resources - no, if your server is pushing 10mb/s or more, then I wouldn't recommend doing it at that time. However, it doesn't do it all the time. On the busy sites I've had, I know when the peaks are and don't even touch the server at those times. >>> If you think that doing resize on server is risky. Yes, it is. You have >>> to dimensionate correctly your hardware, and do a good logic. But it can >>> be done, it's done everyday by a lot of companies. I worked in one of >>> them. I saw. And I could empirecally (exists this word?) test the way >>> you explain and the way I explain. And the result in the real world, is >>> that the little overhead of this last is insignificant compared with the >>> benefits. >> >> In the "real world", people don't do unnecessary work on the server. > > Doesn't seem to happen here. Obviously the EC2 cloud does exactly what > it is intended to do and paid for. > Yea, and if he resized the images offline he wouldn't need all that power. As I told him - I have one VPS handling more hits than that per day. And it's not even a full server. But it does use a lot of PHP and MySQL (plus some perl). >> And BTW - it's not just one user waiting - it's EVERYONE. You're taking >> CPU resources, amongst other things, and there is a limit to what's >> available. What it being taken by resizing is not available to anyone else. > > In a cloud environment CPU power is the least problem. > If he had a true cloud environment, that would be true. But it isn't. >> Not a real problem when you have such a lightly loaded site as you do. >> But I can see why you need all that power to serve so few hits. > > No paragraph of you without insults, directly or subtly. You can't live > without that, right? > Just a fact. I can see why he needs all that power. >>>> First of all, you shouldn't be waiting until the website is complete >>>> before knowing what images you need to resize. >>> >>> This say nothing. >> >> This is called PLANNING. > > You can't plan your visitors. > > Micha > No, but I don't need to plan the visitors. I only need to plan the site. -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | The Natural Philosopher <tnp@invalid.invalid> |
|---|---|
| Date | 2012-05-12 00:38 +0100 |
| Message-ID | <jok7su$8im$3@news.albasani.net> |
| In reply to | #5977 |
Shake wrote: > Jerry Stuckle avait écrit le 11/05/2012 : >> 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! > > Which? > > Is the image going to be accessed directly by its URL, or is loaded > inside a webpage? I am sure is this last case. > > So Loading a PHP script will occur 99.999% if you reescaled the image > previously with a batch or not. All the work of load an script, will be > done always. > > I don't believe that "react" to a 404 error is the good aproach, but > generating dinamically the scaled images when the page that show them is > required. > > And this only need the few lines to test if file exists and generate the > images if not. > > The fact that the image is directly accessed without pasing first for > the php script... is hardly any CPU. The same actions take place: the file must be opened headers constricted and then data streamed. whether apache or PHP does this is scarcely an issue. > > Someone talked about a catalog of image... I am sure they are accessed > through a we, not directly. > > Even if they are accessed via search engines, these search engines have > to visit the scripts that would generate the scaled images. > > Greetings. > > -- 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-11 20:46 -0400 |
| Message-ID | <jokbt4$1ts$2@dont-email.me> |
| In reply to | #5985 |
On 5/11/2012 7:38 PM, The Natural Philosopher wrote: > Shake wrote: >> Jerry Stuckle avait écrit le 11/05/2012 : >>> 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! >> >> Which? >> >> Is the image going to be accessed directly by its URL, or is loaded >> inside a webpage? I am sure is this last case. >> >> So Loading a PHP script will occur 99.999% if you reescaled the image >> previously with a batch or not. All the work of load an script, will >> be done always. >> >> I don't believe that "react" to a 404 error is the good aproach, but >> generating dinamically the scaled images when the page that show them >> is required. >> >> And this only need the few lines to test if file exists and generate >> the images if not. >> >> The fact that the image is directly accessed without pasing first for >> the php script... > > is hardly any CPU. > > The same actions take place: the file must be opened headers constricted > and then data streamed. whether apache or PHP does this is scarcely an > issue. > Wrong. The server is much more efficient at serving images than a PHP script is. But then I would expect this type of statement from a ditch digger who got fired because he didn't know which end of a shovel to use. >> >> Someone talked about a catalog of image... I am sure they are accessed >> through a we, not directly. >> >> Even if they are accessed via search engines, these search engines >> have to visit the scripts that would generate the scaled images. >> >> Greetings. >> >> > > -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | PlastiqueMAN <plastique@man.com> |
|---|---|
| Date | 2012-05-23 22:45 +0200 |
| Message-ID | <201205232245351380-plastique@mancom> |
| In reply to | #5985 |
On 2012-05-11 23:38:06 +0000, The Natural Philosopher said: > Shake wrote: >> Jerry Stuckle avait écrit le 11/05/2012 : >>> 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! >> >> Which? >> >> Is the image going to be accessed directly by its URL, or is loaded >> inside a webpage? I am sure is this last case. >> >> So Loading a PHP script will occur 99.999% if you reescaled the image >> previously with a batch or not. All the work of load an script, will be >> done always. >> >> I don't believe that "react" to a 404 error is the good aproach, but >> generating dinamically the scaled images when the page that show them >> is required. >> >> And this only need the few lines to test if file exists and generate >> the images if not. >> >> The fact that the image is directly accessed without pasing first for >> the php script... > > is hardly any CPU. > > The same actions take place: the file must be opened headers > constricted and then data streamed. whether apache or PHP does this is > scarcely an issue. Sorry to say this, but PHP compared to the default handler in Apache is sloooooow. You can test this simply by writing a php script that copies some large files from a directory to another and then write an identical C program... If this site we're talking about needs to serve a lot of request, I have to agree with Jerry on this one. >> >> Someone talked about a catalog of image... I am sure they are accessed >> through a we, not directly. >> >> Even if they are accessed via search engines, these search engines have >> to visit the scripts that would generate the scaled images. >> >> Greetings.
[toc] | [prev] | [next] | [standalone]
| From | Jerry Stuckle <jstucklex@attglobal.net> |
|---|---|
| Date | 2012-05-24 00:18 -0400 |
| Message-ID | <jpkcqr$3jc$1@dont-email.me> |
| In reply to | #6149 |
On 5/23/2012 4:45 PM, PlastiqueMAN wrote: > On 2012-05-11 23:38:06 +0000, The Natural Philosopher said: > >> Shake wrote: >>> Jerry Stuckle avait écrit le 11/05/2012 : >>>> 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! >>> >>> Which? >>> >>> Is the image going to be accessed directly by its URL, or is loaded >>> inside a webpage? I am sure is this last case. >>> >>> So Loading a PHP script will occur 99.999% if you reescaled the image >>> previously with a batch or not. All the work of load an script, will >>> be done always. >>> >>> I don't believe that "react" to a 404 error is the good aproach, but >>> generating dinamically the scaled images when the page that show them >>> is required. >>> >>> And this only need the few lines to test if file exists and generate >>> the images if not. >>> >>> The fact that the image is directly accessed without pasing first for >>> the php script... >> >> is hardly any CPU. >> >> The same actions take place: the file must be opened headers >> constricted and then data streamed. whether apache or PHP does this is >> scarcely an issue. > > Sorry to say this, but PHP compared to the default handler in Apache is > sloooooow. You can test this simply by writing a php script that copies > some large files from a directory to another and then write an identical > C program... > What do you expect - an interpreted program versus q compiled program? The compiled program will always wind. > If this site we're talking about needs to serve a lot of request, I have > to agree with Jerry on this one. > >>> >>> Someone talked about a catalog of image... I am sure they are >>> accessed through a we, not directly. >>> >>> Even if they are accessed via search engines, these search engines >>> have to visit the scripts that would generate the scaled images. >>> >>> Greetings. > > -- ================== Remove the "x" from my email address Jerry Stuckle JDS Computer Training Corp. jstucklex@attglobal.net ==================
[toc] | [prev] | [next] | [standalone]
| From | Stig Vestøl <stig@vestoldata.no> |
|---|---|
| Date | 2012-05-24 11:40 +0200 |
| Message-ID | <2012052411401812727-stig@vestoldatano> |
| In reply to | #6156 |
On 2012-05-24 04:18:30 +0000, Jerry Stuckle said: > On 5/23/2012 4:45 PM, PlastiqueMAN wrote: >> On 2012-05-11 23:38:06 +0000, The Natural Philosopher said: >> >>> Shake wrote: >>>> Jerry Stuckle avait écrit le 11/05/2012 : >>>>> 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! >>>> >>>> Which? >>>> >>>> Is the image going to be accessed directly by its URL, or is loaded >>>> inside a webpage? I am sure is this last case. >>>> >>>> So Loading a PHP script will occur 99.999% if you reescaled the image >>>> previously with a batch or not. All the work of load an script, will >>>> be done always. >>>> >>>> I don't believe that "react" to a 404 error is the good aproach, but >>>> generating dinamically the scaled images when the page that show them >>>> is required. >>>> >>>> And this only need the few lines to test if file exists and generate >>>> the images if not. >>>> >>>> The fact that the image is directly accessed without pasing first for >>>> the php script... >>> >>> is hardly any CPU. >>> >>> The same actions take place: the file must be opened headers >>> constricted and then data streamed. whether apache or PHP does this is >>> scarcely an issue. >> >> Sorry to say this, but PHP compared to the default handler in Apache is >> sloooooow. You can test this simply by writing a php script that copies >> some large files from a directory to another and then write an identical >> C program... >> > > What do you expect - an interpreted program versus q compiled program? > The compiled program will always wind. 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. > >> If this site we're talking about needs to serve a lot of request, I have >> to agree with Jerry on this one. >> >>>> >>>> Someone talked about a catalog of image... I am sure they are >>>> accessed through a we, not directly. >>>> >>>> Even if they are accessed via search engines, these search engines >>>> have to visit the scripts that would generate the scaled images. >>>> >>>> Greetings.
[toc] | [prev] | [next] | [standalone]
| From | Shake <QUITAESTO@QUITAESTO.NOES> |
|---|---|
| Date | 2012-05-24 12:00 +0200 |
| Message-ID | <jpl0rk$2g8$1@dont-email.me> |
| In reply to | #6159 |
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.
**
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.
[toc] | [prev] | [next] | [standalone]
Page 6 of 8 — ← Prev page 1 2 3 4 5 [6] 7 8 Next page →
Back to top | Article view | comp.lang.php
csiph-web