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 :: Unread Messages :: Show Polls :: Message Navigator
| Subscribe to topic | Bookmark topic 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Windows binaries 64bit for PHP [message #178047] Fri, 11 May 2012 07:23 Go to next message
Erwin Moller is currently offline  Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>> On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>> > On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>> >> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>>>> >>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>>> >>>
>>>> >>> How is this different than pre-scaling the images?
>>>> >>>
>>>> >>
>>>> >> Hi Peter,
>>>> >>
>>>> >> It is different because they are *only* rescaled when not found.
>>>> >>
>>>> >> One approach I used:
>>>> >>
>>>> >> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>> >> (The 300x500 is dimensions needed.)
>>>> >> 2) Check if it exists.
>>>> >> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>> >> case)
>>>> >> and store it.
>>>> >>
>>>> >> One can easily wrap this functionality in a function.
>>>> >>
>>>> >> So the difference is that you don't need a batchjob that apparently
>>>> >> needs months and that will resize many images that are never
>>>> >> needed, or
>>>> >> never needed on that size.
>>>> >> (I have my doubts about the alleged months, but that doesn't matter.)
>>>> >>
>>>> >> Regards,
>>>> >> Erwin Moller
>>>> >>
>>>> >
>>>> > And another waste of time. You should know what size(s) you need,
>>>> > and be
>>>> > able to prescale your images. I don't think I've ever seen a site
>>>> > which
>>>> > needs more than 3-4 sizes for an image, and most sites don't need
>>>> > that.
>>>> >
>>>>
>>>> It is not that simple, Jerry.
>>>> When you have simple design-once website: yes, then I agree.
>>>>
>>>> But when you deal with a team that uses lots of pictures, you don't
>>>> want
>>>> to come back every time some design-guru decides to change the looks of
>>>> the website and needs different formats for the existing pictures. I
>>>> rather make a routine and be done with the problem.
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>>
>>>
>>> It is even easier than that, Erwin. A quick batch file can easily
>>> convert pictures to any size you want.
>>>
>>
>> Yes, I understand that.
>> The point is that I expect less than 1% of them will be used in that
>> format eventually. So it feels like a waste of diskspace to produce them
>> in all formats.
>>
>>
>>> But how often does that happen? My clients don't generally make changes
>>> to their site layout very often. And when they do, there's a lot more to
>>> it than just converting images.
>>>
>>
>> In my case it is a website for city promotion.
>> There is a huge amount of image data, and most is seldom used.
>>
>> Regards,
>> Erwin Moller
>>
>>
>
> So? You know what sizes you need (or at least you should).

How should I know?
These web designers change their mind every congress they visit.

I think it is easier to offer a simple way with dynamic scaling (AND
storing) that takes the best of both worlds: little wasted diskspace and
fast performance.

You don't
> need every possible size from 1x1 to 1000x1000 pixels.

No, but since I don't know beforehand WHAT they want tomorrow, I think
this approach is handy.

Regards,
Erwin Moller


--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
Re: Windows binaries 64bit for PHP [message #178048 is a reply to message #178047] Fri, 11 May 2012 07:38 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 5/11/2012 7:23 AM, Erwin Moller wrote:
> On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
>> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>>> On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> > On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>> >> On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>> >>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>>>> >>>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>>> >>>>
>>>> >>>> How is this different than pre-scaling the images?
>>>> >>>>
>>>> >>>
>>>> >>> Hi Peter,
>>>> >>>
>>>> >>> It is different because they are *only* rescaled when not found.
>>>> >>>
>>>> >>> One approach I used:
>>>> >>>
>>>> >>> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>> >>> (The 300x500 is dimensions needed.)
>>>> >>> 2) Check if it exists.
>>>> >>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>> >>> case)
>>>> >>> and store it.
>>>> >>>
>>>> >>> One can easily wrap this functionality in a function.
>>>> >>>
>>>> >>> So the difference is that you don't need a batchjob that apparently
>>>> >>> needs months and that will resize many images that are never
>>>> >>> needed, or
>>>> >>> never needed on that size.
>>>> >>> (I have my doubts about the alleged months, but that doesn't
>>>> >>> matter.)
>>>> >>>
>>>> >>> Regards,
>>>> >>> Erwin Moller
>>>> >>>
>>>> >>
>>>> >> And another waste of time. You should know what size(s) you need,
>>>> >> and be
>>>> >> able to prescale your images. I don't think I've ever seen a site
>>>> >> which
>>>> >> needs more than 3-4 sizes for an image, and most sites don't need
>>>> >> that.
>>>> >>
>>>> >
>>>> > It is not that simple, Jerry.
>>>> > When you have simple design-once website: yes, then I agree.
>>>> >
>>>> > But when you deal with a team that uses lots of pictures, you don't
>>>> > want
>>>> > to come back every time some design-guru decides to change the
>>>> > looks of
>>>> > the website and needs different formats for the existing pictures. I
>>>> > rather make a routine and be done with the problem.
>>>> >
>>>> > Regards,
>>>> > Erwin Moller
>>>> >
>>>> >
>>>>
>>>> It is even easier than that, Erwin. A quick batch file can easily
>>>> convert pictures to any size you want.
>>>>
>>>
>>> Yes, I understand that.
>>> The point is that I expect less than 1% of them will be used in that
>>> format eventually. So it feels like a waste of diskspace to produce them
>>> in all formats.
>>>
>>>
>>>> But how often does that happen? My clients don't generally make changes
>>>> to their site layout very often. And when they do, there's a lot
>>>> more to
>>>> it than just converting images.
>>>>
>>>
>>> In my case it is a website for city promotion.
>>> There is a huge amount of image data, and most is seldom used.
>>>
>>> Regards,
>>> Erwin Moller
>>>
>>>
>>
>> So? You know what sizes you need (or at least you should).
>
> How should I know?
> These web designers change their mind every congress they visit.
>

No problem - a simple batch job rescales the images to whatever size you
specify.

> I think it is easier to offer a simple way with dynamic scaling (AND
> storing) that takes the best of both worlds: little wasted diskspace and
> fast performance.
>
> You don't
>> need every possible size from 1x1 to 1000x1000 pixels.
>
> No, but since I don't know beforehand WHAT they want tomorrow, I think
> this approach is handy.
>
> Regards,
> Erwin Moller
>
>

So? They tell you they need a new size. Run the batch job to create
the files. It would take you maybe 10 seconds to type the command in.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Windows binaries 64bit for PHP [message #178051 is a reply to message #178048] Fri, 11 May 2012 09:44 Go to previous messageGo to next message
Erwin Moller is currently offline  Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
> On 5/11/2012 7:23 AM, Erwin Moller wrote:
>> On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
>>> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>>>> On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>>> > On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> >> On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>> >>> On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>> >>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>>>> >>>>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>>> >>>>>
>>>> >>>>> How is this different than pre-scaling the images?
>>>> >>>>>
>>>> >>>>
>>>> >>>> Hi Peter,
>>>> >>>>
>>>> >>>> It is different because they are *only* rescaled when not found.
>>>> >>>>
>>>> >>>> One approach I used:
>>>> >>>>
>>>> >>>> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>> >>>> (The 300x500 is dimensions needed.)
>>>> >>>> 2) Check if it exists.
>>>> >>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>> >>>> case)
>>>> >>>> and store it.
>>>> >>>>
>>>> >>>> One can easily wrap this functionality in a function.
>>>> >>>>
>>>> >>>> So the difference is that you don't need a batchjob that apparently
>>>> >>>> needs months and that will resize many images that are never
>>>> >>>> needed, or
>>>> >>>> never needed on that size.
>>>> >>>> (I have my doubts about the alleged months, but that doesn't
>>>> >>>> matter.)
>>>> >>>>
>>>> >>>> Regards,
>>>> >>>> Erwin Moller
>>>> >>>>
>>>> >>>
>>>> >>> And another waste of time. You should know what size(s) you need,
>>>> >>> and be
>>>> >>> able to prescale your images. I don't think I've ever seen a site
>>>> >>> which
>>>> >>> needs more than 3-4 sizes for an image, and most sites don't need
>>>> >>> that.
>>>> >>>
>>>> >>
>>>> >> It is not that simple, Jerry.
>>>> >> When you have simple design-once website: yes, then I agree.
>>>> >>
>>>> >> But when you deal with a team that uses lots of pictures, you don't
>>>> >> want
>>>> >> to come back every time some design-guru decides to change the
>>>> >> looks of
>>>> >> the website and needs different formats for the existing pictures. I
>>>> >> rather make a routine and be done with the problem.
>>>> >>
>>>> >> Regards,
>>>> >> Erwin Moller
>>>> >>
>>>> >>
>>>> >
>>>> > It is even easier than that, Erwin. A quick batch file can easily
>>>> > convert pictures to any size you want.
>>>> >
>>>>
>>>> Yes, I understand that.
>>>> The point is that I expect less than 1% of them will be used in that
>>>> format eventually. So it feels like a waste of diskspace to produce
>>>> them
>>>> in all formats.
>>>>
>>>>
>>>> > But how often does that happen? My clients don't generally make
>>>> > changes
>>>> > to their site layout very often. And when they do, there's a lot
>>>> > more to
>>>> > it than just converting images.
>>>> >
>>>>
>>>> In my case it is a website for city promotion.
>>>> There is a huge amount of image data, and most is seldom used.
>>>>
>>>> Regards,
>>>> Erwin Moller
>>>>
>>>>
>>>
>>> So? You know what sizes you need (or at least you should).
>>
>> How should I know?
>> These web designers change their mind every congress they visit.
>>
>
> No problem - a simple batch job rescales the images to whatever size you
> specify.

That is one way.
It will take up a huge amount of diskspace, defining images that are
never used.
I don't see the point in approaching it like that.

Of course: when you have a small site that seldom changes, there is no
need for the approach, but when you deal with many images and designers
that want them in other formats on a regular basis, it is smarter to
define them on demand.
All you need for this is some approach that catches missing images,
which van be easily handles by, for example, Apache.

To be honest: I don't understand your reluctance at all.

Regards,
Erwin Moller


--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
Re: Windows binaries 64bit for PHP [message #178055 is a reply to message #178051] Fri, 11 May 2012 10:30 Go to previous messageGo to next message
Jerry Stuckle is currently offline  Jerry Stuckle
Messages: 2598
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 5/11/2012 9:44 AM, Erwin Moller wrote:
> On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
>> On 5/11/2012 7:23 AM, Erwin Moller wrote:
>>> On 5/9/2012 6:23 PM, Jerry Stuckle wrote:
>>>> On 5/9/2012 10:54 AM, Erwin Moller wrote:
>>>> > On 5/9/2012 4:38 PM, Jerry Stuckle wrote:
>>>> >> On 5/9/2012 10:23 AM, Erwin Moller wrote:
>>>> >>> On 5/9/2012 3:17 PM, Jerry Stuckle wrote:
>>>> >>>> On 5/9/2012 3:56 AM, Erwin Moller wrote:
>>>> >>>>> On 5/9/2012 4:29 AM, Peter H. Coffin wrote:
>>>> >>>>>> On Tue, 08 May 2012 22:25:26 +0200, 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.
>>>> >>>>>>
>>>> >>>>>> How is this different than pre-scaling the images?
>>>> >>>>>>
>>>> >>>>>
>>>> >>>>> Hi Peter,
>>>> >>>>>
>>>> >>>>> It is different because they are *only* rescaled when not found.
>>>> >>>>>
>>>> >>>>> One approach I used:
>>>> >>>>>
>>>> >>>>> 1) Need image xyz_2012_march_nr12_300x500.jpg
>>>> >>>>> (The 300x500 is dimensions needed.)
>>>> >>>>> 2) Check if it exists.
>>>> >>>>> If not: Create it out of original (xyz_2012_march_nr12.jpg in this
>>>> >>>>> case)
>>>> >>>>> and store it.
>>>> >>>>>
>>>> >>>>> One can easily wrap this functionality in a function.
>>>> >>>>>
>>>> >>>>> So the difference is that you don't need a batchjob that
>>>> >>>>> apparently
>>>> >>>>> needs months and that will resize many images that are never
>>>> >>>>> needed, or
>>>> >>>>> never needed on that size.
>>>> >>>>> (I have my doubts about the alleged months, but that doesn't
>>>> >>>>> matter.)
>>>> >>>>>
>>>> >>>>> Regards,
>>>> >>>>> Erwin Moller
>>>> >>>>>
>>>> >>>>
>>>> >>>> And another waste of time. You should know what size(s) you need,
>>>> >>>> and be
>>>> >>>> able to prescale your images. I don't think I've ever seen a site
>>>> >>>> which
>>>> >>>> needs more than 3-4 sizes for an image, and most sites don't need
>>>> >>>> that.
>>>> >>>>
>>>> >>>
>>>> >>> It is not that simple, Jerry.
>>>> >>> When you have simple design-once website: yes, then I agree.
>>>> >>>
>>>> >>> But when you deal with a team that uses lots of pictures, you don't
>>>> >>> want
>>>> >>> to come back every time some design-guru decides to change the
>>>> >>> looks of
>>>> >>> the website and needs different formats for the existing pictures. I
>>>> >>> rather make a routine and be done with the problem.
>>>> >>>
>>>> >>> Regards,
>>>> >>> Erwin Moller
>>>> >>>
>>>> >>>
>>>> >>
>>>> >> It is even easier than that, Erwin. A quick batch file can easily
>>>> >> convert pictures to any size you want.
>>>> >>
>>>> >
>>>> > Yes, I understand that.
>>>> > The point is that I expect less than 1% of them will be used in that
>>>> > format eventually. So it feels like a waste of diskspace to produce
>>>> > them
>>>> > in all formats.
>>>> >
>>>> >
>>>> >> But how often does that happen? My clients don't generally make
>>>> >> changes
>>>> >> to their site layout very often. And when they do, there's a lot
>>>> >> more to
>>>> >> it than just converting images.
>>>> >>
>>>> >
>>>> > In my case it is a website for city promotion.
>>>> > There is a huge amount of image data, and most is seldom used.
>>>> >
>>>> > Regards,
>>>> > Erwin Moller
>>>> >
>>>> >
>>>>
>>>> So? You know what sizes you need (or at least you should).
>>>
>>> How should I know?
>>> These web designers change their mind every congress they visit.
>>>
>>
>> No problem - a simple batch job rescales the images to whatever size you
>> specify.
>
> That is one way.
> It will take up a huge amount of diskspace, defining images that are
> never used.
> I don't see the point in approaching it like that.
>
> Of course: when you have a small site that seldom changes, there is no
> need for the approach, but when you deal with many images and designers
> that want them in other formats on a regular basis, it is smarter to
> define them on demand.
> All you need for this is some approach that catches missing images,
> which van be easily handles by, for example, Apache.
>
> To be honest: I don't understand your reluctance at all.
>
> Regards,
> Erwin Moller
>
>

In case you haven't figured it out - disk space is cheap - much cheaper
than CPU. But then if you're only getting 200 hits a day I guess the
extra load doesn't make any difference.

--
==================
Remove the "x" from my email address
Jerry Stuckle
JDS Computer Training Corp.
jstucklex(at)attglobal(dot)net
==================
Re: Windows binaries 64bit for PHP [message #178060 is a reply to message #178051] Fri, 11 May 2012 14:38 Go to previous messageGo to next message
Peter H. Coffin is currently offline  Peter H. Coffin
Messages: 245
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On Fri, 11 May 2012 15:44:55 +0200, Erwin Moller wrote:
> On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
>>
>> No problem - a simple batch job rescales the images to whatever size you
>> specify.
>
> That is one way.
> It will take up a huge amount of diskspace, defining images that are
> never used.
> I don't see the point in approaching it like that.

Why are the designers asking you for image sizes that will never be
used? (Aside from the admittedly-true "They're WEB DESIGNERS"...)

--
Windows gives you a nice view of clouds so you can't see any potentially
useful boot time messages.
-- Bill Hay in the Monastery
Re: Windows binaries 64bit for PHP [message #178107 is a reply to message #178060] Mon, 14 May 2012 04:48 Go to previous message
Erwin Moller is currently offline  Erwin Moller
Messages: 228
Registered: September 2010
Karma: 0
Senior Member
add to buddy list
ignore all messages by this user
On 5/11/2012 8:38 PM, Peter H. Coffin wrote:
> On Fri, 11 May 2012 15:44:55 +0200, Erwin Moller wrote:
>> On 5/11/2012 1:38 PM, Jerry Stuckle wrote:
>>>
>>> No problem - a simple batch job rescales the images to whatever size you
>>> specify.
>>
>> That is one way.
>> It will take up a huge amount of diskspace, defining images that are
>> never used.
>> I don't see the point in approaching it like that.
>
> Why are the designers asking you for image sizes that will never be
> used? (Aside from the admittedly-true "They're WEB DESIGNERS"...)
>

Hi Peter,

The content makers use these pictures and the designers create the
presentation layers.

It worked like this:
- We have a stock of high res pictures on some dedicated server.
- A bunch of domains (all related) use these pictures, in different
dimensions.
- A lot of third parties request the info and will use it in ever
changing context (RSS feeds, websites, mobile apps, flyers, desktop
publishing, etc).

Now there are (at least) two approaches:
1) pull the pictures from the pictureserver, and resize them in the
domain where they are used.
2) Let the picture server decide (based on filename) what dimensions the
requested picture should be. We did this.

The pictureserver had some services like delivering small pictures on
some subject, so the content maker can pick the right one.
The pictureserver also can count how often which picture is requested:
in some cases there were fees involved to the owner of the picture. (Of
course this can all be circumvented.)

There are different approaches to solve the same problem: I know that.
I merely posted in this thread to say that dynamic resizing combined
with storing that file can have it uses in certain situations.

I also think it isn't always the smartest solution to resize them all
beforehand, like Jerry prefers.

Regards,
Erwin Moller

--
"That which can be asserted without evidence, can be dismissed without
evidence."
-- Christopher Hitchens
Quick Reply
Formatting Tools:   
  Switch to threaded view of this topic Create a new topic
Previous Topic: Stats comp.lang.php (last 7 days)
Next Topic: Re: PHP Eassy and Difficult
Goto Forum:
  

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

Current Time: Sat Dec 16 11:42:38 EST 2017

Total time taken to generate the page: 0.00767 seconds