[Tickets #13566] Re: Multi-thread performance while uploading

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: https://bugs.horde.org/ticket/13566
------------------------------------------------------------------------------
  Ticket             | 13566
  Updated By         | Michael Rubinsky <mrubinsk at horde.org>
  Summary            | Multi-thread performance while uploading
  Queue              | Ansel
  Version            | 3.0.1
  Type               | Enhancement
-State              | Feedback
+State              | Rejected
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Michael Rubinsky <mrubinsk at horde.org> (2014-09-15 23:33) wrote:

>> Neither Horde nor PHP has control over the number of CPUs in use on
>> the server. the only thing I could suggest is making sure that the
>> configuration for auto generating the views is turned off and see if
>> that helps
>
> I've actually narrowed it down to the fact that even if you open 3  
> tab in the same browser somehow apache consider it the same session

Of course. Anything coming from the same browser/login is going to be  
the same session.

> and thus don't spread the work on 3 worker. Though if you open one  
> in firefox and one in chrome those are considered as 2 session and  
> will be working on 2 worker.
>
> I might be mistaken in the explication but the bahavior is what I noticed.
>
> Would there be a workaround possible with that to fire up more  
> worker to increase the picture processing ?

No. Userland code has no control over which PHP instance executes the  
code (unless you start talking about using the various forking  
functions in PHP and we are NOT going there). The only possibility is  
to write a new backend handler for Horde_Queue (which queues the  
operations when automatically generating the image thumbnails on  
upload). Note that this would only help once the files are fully  
uploaded, and not affect the actual uploaded of the files.

> Like during the upload I noticed it's only working on 1 picture at a  
> time instead of let's say 4 ( configurable the maximum of  
> simultanuous upload from a user )

The core logic that handles the uploading is done via a third party  
library called Plupload, and this does not currently support  
simultaneous uploads, or immediate-start-on-drop operations. Even if  
we did have the functionality, though, you are still stuck with the  
problem of it all being done from a single session.