FUDforum
Fast Uncompromising Discussions. FUDforum will get your users talking.

Home » Imported messages » comp.lang.php » Re: Windows binaries 64bit for PHP
Show: Today's Messages :: Polls :: Message Navigator
Return to the default flat view Create a new topic Submit Reply
Re: Windows binaries 64bit for PHP [message #178085 is a reply to message #178083] Sat, 12 May 2012 15:04 Go to previous messageGo to previous message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma:
Senior Member
On 5/12/2012 8:42 AM, Shake wrote:
> I thought you don't understood.
>
> I would use the catalogue example:
>
> People visits this page to see the image catalogue. Search engines
> visits this page to index images.
>
> If nobody human or machine have entered to this page, there is no
> directy linked image nowhere.
>

The link is there, whether a human or machine has requested the page or
not. Links don't just magically appear!

Whether the link has been accessed or not is a different story - but
immaterial to whether it exists or not.

> So, at this point nobody knows any url to any image of this site. And
> there is no image that could be accessed.
>

Still doesn't make any difference whether someone knows about the image
or not.

> The only way to knwo about one of these images is when anyone enter the
> php page. And when this occurs, reescaling process will be done if
> necesary.
>

At additional overhead to the server. This overhead can be completely
eliminated by simply resizing the images offline.

> Never, any image will be directly delivered without previosly have been
> executed the php.
>

And once the images have been created offline, the server doesn't have
to execute ANY PHP to deliver the image.

> We have the image /catalogue/images/size_1/123213.jpg Original
> We have the image /catalogue/images/size_2/123213.jpg Scaled
> We have the image /catalogue/images/size_3/123213.jpg No Scaled.
>
> The catalogue was listed throught /catalogue/index.php that yesterday
> was modified using a new size fo thumbnails (size_3).
>
> The third size was created yesterday. Nobody knows his existence, there
> is no link to it in any web, search engine or human brain. So nobody
> could access. That is a lucky thing, because the image no exist.
>

If there is no link, then why would the image be created?

> When the first visit is done to the /catalogue/index.php the size_2
> images start to be generated. If the visit is from a search engine, then
> the new images are indexed and could be directly accessed.
>

And if the images are created offline, none of that needs to be done.
The images can be sent without any PHP involvement at all.

> so /catalogue/index.php is executed always previous to put on the net
> the existence of new images. Included if we have batch reescaled them.
> These images will not have internet existence never if the
> catalogue/index.php is not executed. with or without reescaling.
>

But if you're listing them in the catalog, then there is a link to them.

> And then, this mean that all the supossed overhead about executing PHP
> always happen even if you batched the process.
>

Sure, but the batch process is done on another machine, taking
unnecessary work off the server.

> And it's obvious. we are talking about web pages that are created with php.
>

Which has nothing to do with resizing of images. The page with the link
MAY be a PHP page. But it could also be a Perl page, a Python page, a
Ruby (on Rails) page or even static HTML.

> I worked for four years in a website for artists. Not the bigger company
> but with reasonable traffic, 8 millions page visits per month, por than
> 250.000 pages per day. And about 1 million image artwork. A lot of them
> of big resolucion.
>

8 million hits a month is a bit below average, but a lot more than most
of the people in this newsgroup work on.

> And in this company we fight against this problem. In some cases we
> decided to use batch process and in other cases we decided to do
> "on-the-fly".
>

Sure, doing the batch process means less work for the server.

> Big images requires watermarking and some other processes, too slow to
> do on-fly. The reescaling required 3 weeks to be done , using three 3
> computers.
>

You need to get some better computers. 1M images shouldn't take
anywhere near 9 computer weeks to do! But then maybe you're using
Windows, which has significant overhead. Of course you could also do it
in a compiled language like C, which will also tremendously speed up the
process (a C program to do something like this is pretty simple).

> Other times, for new set of small sizes, we used on the fly. withouth
> usign 404 to react to.
>

Good you're not using the 404. But it's still a lot of unnecessary
overhead.

How long would it take your 3 computers to resize all the images you're
currently doing on your server? You're dumping that amount of overhead
plus more on the server.

> Just first time any one enters a page that have new images, new images
> were generated. And never happened that any image have been accesses
> directly previous to its generation.
>

Which is putting unnecessary overhead on the server.

> The images are always served directly throught lighttp, the php necesary
> to generate images was always inside the php app that generate the web
> pages.
>
> Greetings
>
>

You still have significant overhead on the server. Plus now you've
added unnecessary complexity to your application.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
[Message index]
 
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Read Message
Previous Topic: is_dir true from cli, false from Apache
Next Topic: in_array performance in unsorted vs sorted array
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ]

Current Time: Wed Oct 02 02:28:38 GMT 2024

Total time taken to generate the page: 0.06449 seconds