On Sat, 2010-05-29 at 09:49 -0700, Bharat Mediratta wrote:
>
> G3 wi
>
>
> Brandon Sussman wrote:
> > I have a client that is using G2 for a special tracking application. No
> > pretty features or effects are used or needed.
> >
> > The image base is big ( 100,000 images in many hundreds of albums) and
> > sub-albums are often moved between albums.
> >
> > Some sql calls are timing out. Moves are slowing. Life is not good.
> >
> > 1. Is this size image base beyond fair expection for a well performing
> > G2 gallery?
>
> 100k photos should be no problem for G2. What would be a problem is if
> you have a huge number of per-user and per-group permissions. What SQL
> calls are timing out?
>
> Where's the performance bottleneck, on the PHP side or MySQL? Are you
> I/O bound or RAM bound?
>
> Have you read this page:
> http://codex.gallery2.org/Gallery2:Performance_Tips
>
> What optimization have you done already?
>
> > 2. What about G3 - might we expect bigger, better?
>
> G3 is lighter, faster. It will handle 100k photos just fine, and its
> performance characteristics at that level should be much better than G2,
> but we get there by limiting features (radically reducing permissions,
> getting rid of the image firewall, etc).
The limits are no problem at all for this client - this is not a family
album site. However I am mindful of a narrow user focus for G3 and this
is an edge use case - photos as part of project management workflow to
billing (photos of completed maintenance of a property -> payment.
Also we would have to slightly retrain the worker-bees :)
Mid-high-season :(
If you want a great high volume test case for G3, we got it. We are
hammering a limited function set, but very hard.
G3 is not prod released and I am paranoid about that. I used to be in
charge of denying pre-prod releases to foriegn sales offices that had
moles in R&D :)
We'll wait for a prod release!
>
> Without knowing what your bottleneck is, it's hard to say how to improve
> it. If your host is using ancient or overloaded hardware then yeah you
> may not get much better. But there are lots of ways to improve your
> system to make PHP/MySQL run faster...
>
I agree.
Their hw is pretty modern but may not be tuned well for us - it is their
very new generic cloud offering. There have been disk array issues as
well as some other issues. Anecdotal evidence suggests we ran better
(approximately same loads) in their conventional virtual server. I see
mysql timeouts and errors in G2 that are intermittent but I am guessing
that G2 is healthy but pushing their config too hard.
I wonder if breaking the load in two would help.
--
Lamb, Poultry, Eggs, Quilts and Web Sites - Think Locally, Buy Locally!
Webster Ridge Farm - http://WebsterRidge.com (603)648-2595

G3 wi
Brandon Sussman wrote:
> I have a client that is using G2 for a special tracking application. No
> pretty features or effects are used or needed.
>
> The image base is big ( 100,000 images in many hundreds of albums) and
> sub-albums are often moved between albums.
>
> Some sql calls are timing out. Moves are slowing. Life is not good.
>
> 1. Is this size image base beyond fair expection for a well performing
> G2 gallery?
100k photos should be no problem for G2. What would be a problem is if
you have a huge number of per-user and per-group permissions. What SQL
calls are timing out?
Where's the performance bottleneck, on the PHP side or MySQL? Are you
I/O bound or RAM bound?
Have you read this page:
http://codex.gallery2.org/Gallery2:Performance_Tips
What optimization have you done already?
> 2. What about G3 - might we expect bigger, better?
G3 is lighter, faster. It will handle 100k photos just fine, and its
performance characteristics at that level should be much better than G2,
but we get there by limiting features (radically reducing permissions,
getting rid of the image firewall, etc).
> 3. Beyond maint -> db optimization, is any db rebuild possible or even
> necessary.
Yes, but probably not.
> The web host is telling us we are running out of hardware horsepower
> (well -virtual/cloud/imaginary/whatever horsepower). I am beginning to
> agree but do not wish to upgrade the client without a good probability
> of seeing better raw performance and if there are limits to what we can
> expect of G2 I'd better know now!
Without knowing what your bottleneck is, it's hard to say how to improve
it. If your host is using ancient or overloaded hardware then yeah you
may not get much better. But there are lots of ways to improve your
system to make PHP/MySQL run faster...
-Bharat

I have a client that is using G2 for a special tracking application. No
pretty features or effects are used or needed.
The image base is big ( 100,000 images in many hundreds of albums) and
sub-albums are often moved between albums.
Some sql calls are timing out. Moves are slowing. Life is not good.
1. Is this size image base beyond fair expection for a well performing
G2 gallery?
2. What about G3 - might we expect bigger, better?
3. Beyond maint -> db optimization, is any db rebuild possible or even
necessary.
The web host is telling us we are running out of hardware horsepower
(well -virtual/cloud/imaginary/whatever horsepower). I am beginning to
agree but do not wish to upgrade the client without a good probability
of seeing better raw performance and if there are limits to what we can
expect of G2 I'd better know now!
-- Brandon

On Thu, 2010-05-27 at 15:06 -0700, Stephen Cupp wrote:
> Is there anyone with some Drupal experience that can fix what the 6.16 update did
> to the integration module. I tried sending an email to profix898 (the module
> maintainer but didn't hear back). Here is a link to the issue.
> http://drupal.org/node/734716
>
I have engaged in gallery<-> adventures. Thes adventures can be
challenging.
>From a quick read of the issue, I would choose the method that involves
restoring the pre-upgrade backup and reserving a copy of .htaccess
before redoing the upgrade, then doing surgery on the .htaccess file.
It is not strictly a drupal-experience-heavy activity - more a
realization that there are rough edges and that manual technical labor
is necessary.
--
Brandon <Brandon@...>

The problem is there is no way to set up a new site unless you download
the old Drupal then get the G2 integration working then upgrading Drupal
while protecting the stuff in .htaccess.
Stephen Cupp
"Goaltending is a normal job, Sure! How would you like it in your job
if every time you made a mistake, a red light went on over your desk and
fifteen thousand people stood up and yelled at you?" -Hall of Fame
Goaltender Jacques Plante
On 5/27/2010 6:23 PM, Chris Kelly wrote:
> On May 27, 2010, at 6:06 PM, Stephen Cupp wrote:
>> Is there anyone with some Drupal experience that can fix what the 6.16 update did
>> to the integration module. I tried sending an email to profix898 (the module
>> maintainer but didn't hear back). Here is a link to the issue.
>> http://drupal.org/node/734716
>
> Here's my not-a-solution solution:
>
> http://ckdake.com/content/2009/drupal-upgrades.html
>
> Both of these will either prevent your .htaccess from getting clobbered or let you easily roll back whatever happened.
>
> -Chris

On May 27, 2010, at 6:06 PM, Stephen Cupp wrote:
> Is there anyone with some Drupal experience that can fix what the 6.16 update did
> to the integration module. I tried sending an email to profix898 (the module
> maintainer but didn't hear back). Here is a link to the issue.
> http://drupal.org/node/734716
Here's my not-a-solution solution:
http://ckdake.com/content/2009/drupal-upgrades.html
Both of these will either prevent your .htaccess from getting clobbered or let you easily roll back whatever happened.
-Chris

Is there anyone with some Drupal experience that can fix what the 6.16 update did
to the integration module. I tried sending an email to profix898 (the module
maintainer but didn't hear back). Here is a link to the issue.
http://drupal.org/node/734716
Thanks,
Stephen Cupp

Hi Alex,
As Bharat has explained, the Gallery development team is no-further-interest
on Gallery2 however there are several hundreds of thousands (or millions) of
installations and an active support forum at
http://gallery.menalto.com/forum where people would be absolutely
*delighted* to have any information that will help them use G2 better and
get less spam.
Outside of the Gallery development team I'd guess I have as much code-level
experience with G2 as anyone else - and I will be very pleased to work
through your suggestions and post whatever the result is to the G2 support
forums where at least the information will be in the public domain. Given
that there are no future releases of G2 planned the best place for your
information is directly in front of the people who use G2.
Thanks for your support!
-Alec
----- Original Message -----
From: "Bharat Mediratta" <bharat@...>
To: "Alex Shiels" <alex@...>
Cc: "Gallery-Devel" <gallery-devel@...>
Sent: Tuesday, May 11, 2010 3:21 AM
Subject: Re: [Gallery-devel] Akismet support in Gallery 2
cc: gallery-devel
Alex Shiels wrote:
> Hi,
>
> I understand you're the developer of Gallery 2, is that correct?
>
> I work for Automattic Inc. We run the Akismet spam filtering service.
> There are some shortcomings in the way Gallery 2 uses Akismet, and
> I'm hoping I can help you to fix them.
>
> Can we chat in email? You can forward this on if there is someone
> else in a better position to help.
Hi, Alex. We're pretty heads down on Gallery 3 right now so it's much
more important to me that G3 supports Akismet properly. Can you
elaborate on what's wrong with the G2 support, and have we made that
same mistake in G3? We're not aiming to put out further G2 releases so
even if we fix it up now, there's no release vehicle for the change.
However, we'd definitely like to get it right in G3.
-Bharat
------------------------------------------------------------------------------
__[ g a l l e r y - d e v e l ]_________________________
[ list info/archive --> http://gallery.sf.net/lists.php ]
[ gallery info/FAQ/download --> http://gallery.sf.net ]
--------------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - http://www.avg.com
Version: 9.0.819 / Virus Database: 271.1.1/2866 - Release Date: 05/10/10
19:26:00

cc: gallery-devel
Alex Shiels wrote:
> Hi,
>
> I understand you're the developer of Gallery 2, is that correct?
>
> I work for Automattic Inc. We run the Akismet spam filtering service.
> There are some shortcomings in the way Gallery 2 uses Akismet, and
> I'm hoping I can help you to fix them.
>
> Can we chat in email? You can forward this on if there is someone
> else in a better position to help.
Hi, Alex. We're pretty heads down on Gallery 3 right now so it's much
more important to me that G3 supports Akismet properly. Can you
elaborate on what's wrong with the G2 support, and have we made that
same mistake in G3? We're not aiming to put out further G2 releases so
even if we fix it up now, there's no release vehicle for the change.
However, we'd definitely like to get it right in G3.
-Bharat

Tim Almdal wrote:
> oops, 2nd thought. We already use rest/gallery/items/35?url=..... to
> return the details for a list of urls. So what do you think is the most
> consistent way to approach this, go with your
> approach((rest/gallery/items?ancestors_for=35) or do something like
> rest/gallery/items/35?ancestors_for=true. I think the latter might be
> more consistent. But I'm open to alternatives.
We shouldn't be doing that. "items" is a collection by itself --
"items/35" is an invalid resource. So our new api for items would be:
items?url=url1,url2
items?ancestors_for=35
(please add docs to the function similar to what we do in item_rest::get())
-Bharat
>
> Tim
>
> On 5/9/2010 1:28 PM, Tim Almdal wrote:
>> I think that's the best approach
>> (rest/gallery/items?ancestors_for=nn), it makes a lot of sense
>>
>> Thanks
>> Tim
>>
>> On 5/9/2010 12:02 PM, Bharat Mediratta wrote:
>>> Tim Almdal wrote:
>>>> I can't remember if there is an API call to get the (grand-)*parents
>>>> of a particular item.
>>>>
>>>> Is this something worth returning in the rest side-band information
>>>> ("ancestors") or should we make it an option on the
>>>> rest/gallery/item?ancestors=1
>>>>
>>>> The use case that I'm thinking of is in organize, if the album is
>>>> not the root album, then I think organize should open the album tree
>>>> to the appropriate album, even if it is several levels down in the
>>>> tree.
>>>>
>>>> thoughts?
>>>>
>>>> I can probably get around adding it to rest, and just put it in the
>>>> PHP generated view as an input parameter if I had to. But like I
>>>> said, I can't remember if there is already an API method to retrieve
>>>> the ancestors of an item. If not is there an easy way (using the
>>>> left and right pointers) to find the ancestors?
>>>
>>> There's no way to do that currently. Since we're talking about
>>> getting a set of items based on a specific criteria, this seems like
>>> an appropriate thing for a REST query. The question is, where should
>>> we put it.
>>>
>>> Let's say we want the ancestors of item with id 35. It sounds like
>>> you're proposing:
>>>
>>> rest/gallery/item/35?ancestors=1
>>>
>>> That's a little weird since theoretically we're querying item 35 as a
>>> collection, which is typically about what's in that item's collection
>>> which implies that it's an item.
>>>
>>> Instead we could try:
>>> rest/gallery/items?ancestors_for=35
>>>
>>> That would query the entire collection all items that are ancestors
>>> of the item.
>>>
>>> Want to give that a shot?
>>> -Bharat
>>>
>>>
>>>
>>> No virus found in this incoming message.
>>> Checked by AVG - http://www.avg.com
>>> Version: 9.0.819 / Virus Database: 271.1.1/2863 - Release Date: 05/08/10 23:26:00
>>>
>>>

Tim Almdal wrote:
> I can't remember if there is an API call to get the (grand-)*parents of
> a particular item.
>
> Is this something worth returning in the rest side-band information
> ("ancestors") or should we make it an option on the
> rest/gallery/item?ancestors=1
>
> The use case that I'm thinking of is in organize, if the album is not
> the root album, then I think organize should open the album tree to the
> appropriate album, even if it is several levels down in the tree.
>
> thoughts?
>
> I can probably get around adding it to rest, and just put it in the PHP
> generated view as an input parameter if I had to. But like I said, I
> can't remember if there is already an API method to retrieve the
> ancestors of an item. If not is there an easy way (using the left and
> right pointers) to find the ancestors?
There's no way to do that currently. Since we're talking about getting
a set of items based on a specific criteria, this seems like an
appropriate thing for a REST query. The question is, where should we
put it.
Let's say we want the ancestors of item with id 35. It sounds like
you're proposing:
rest/gallery/item/35?ancestors=1
That's a little weird since theoretically we're querying item 35 as a
collection, which is typically about what's in that item's collection
which implies that it's an item.
Instead we could try:
rest/gallery/items?ancestors_for=35
That would query the entire collection all items that are ancestors of
the item.
Want to give that a shot?
-Bharat

+1
Kevin
On Sun, May 2, 2010 at 4:10 PM, Bharat Mediratta <bharat@...> wrote:
>
> +1 from me. The resized image is the only "context" on that page so
> there's no need for a separate context menu for it. This would make it
> more consistent with the menus when you're viewing an album.
>
> Dave Moore wrote:
> > +1 for the move to under the 'Photo options'
> >
> > Dave
>

SergeD recommended a change that I'm considering making. I'd like to get some feed back first.
The recommendation is move the photo view's context menu options to appear under "Photo options" in the site menu. After moving the options, remove the context menu altogether.
https://sourceforge.net/apps/trac/gallery/ticket/1077
I've not been happy with the context menu on photo pages for some time. It's isolated and I'm afraid it's easily missed in its current position under resized photos.
Thoughts?

Will do. Sorry I missed today's meeting...
On Apr 30, 2010, at 3:53 PM, Bharat Mediratta wrote:
>
> I took a swing at this and didn't get it done. There are a variety of UI issues that are probably easy to overcome, but I'm not the best person for the job. Chad, can you take a look? I stashed all my changes in the "jquery_update" branch so that you can get up to speed quickly. Details are in this ticket:
>
> https://sourceforge.net/apps/trac/gallery/ticket/1113#comment:2
>
> -Bharat
>

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details