Nova Action generate process takes to much time

[tufankilicaslan]

• Laravel Version: 5.7.16
• Nova Version: 1.2.0
• PHP Version: 7.2.10

Description:

When generating a Nova Action over thousand of records, there is a long time wait on browser even if this is a queued action. Actually it takes time to divide target models to chunks & create records on action_events table before it sent to the nova action. I think this action_events table records generate should be done in background, without holding user on browser for a long time.

Even I close the "action generate popup" after click "run action" button, the process is keep going on to generate in background. So, I think it's not make sense to keep user on browser just for showing "action run successfully" message, if this is a queued action.

Steps To Reproduce:

• Create a simple model / resource file with thousand of records
• Create a simple queued action
• Run the action

[alexbowers]

Can you share an example of your Action code?

[tufankilicaslan]

Ok, to make it more clear here is my test "action" code, with just simple loop each model, without doing any action actually. I am using redis server + horizon for queueable jobs, but there is no problem with job management, the issue is while dispatching actions to nova action class.

Also added some screen shots , if it helps. Thank you.

class SetActive extends Action implements ShouldQueue
{
    use InteractsWithQueue, Queueable, SerializesModels;

    /**
     * Perform the action on the given models.
     *
     * @param  \Laravel\Nova\Fields\ActionFields  $fields
     * @param  \Illuminate\Support\Collection  $models
     * @return mixed
     */
    public function handle(ActionFields $fields, Collection $models)
    {
            foreach ($models as $model) {
                // do nothing just loop each model
            }
    }

    /**
     * Get the fields available on the action.
     *
     * @return array
     */
    public function fields()
    {
        return [];
    }
}

[alexbowers]

Thanks, that helps.

I'll take a look at it now.

Thanks :)

[alexbowers]

Ok for me anything > 200 was causing SQL errors (using sqlite).

I have figured out how to fix that, and I can replicate performance issues.

5000 queued jobs takes ~ 20s on my machine.

[tufankilicaslan]

For me, 5000 records, almost takes 5 minutes (using Mysql.) Which is not good.

I think need to improve request chunks and dispatching mechanism in Action class. For the queued jobs, this generate process should be done in background.

        $result = $request->chunks(static::$chunkCount, function ($models) use ($request, $method, &$wasExecuted) {
            $models = $models->filterForExecution($request);

            if (count($models) > 0) {
                $wasExecuted = true;
            }

            return DispatchAction::forModels(
                $request, $this, $method, $models
            );
        });

[tufankilicaslan]

I think i found the issue which makes it slow.

nova/src/Actions/DispatchAction.php line 52

    /**
     * Dispatch the given action in the background.
     *
     * @param  \Laravel\Nova\Http\Requests\ActionRequest  $request
     * @param  \Laravel\Nova\Actions\Action  $action
     * @param  string  $method
     * @param  \Illuminate\Support\Collection  $models
     * @return void
     */
    protected static function queueForModels(ActionRequest $request, Action $action, $method, Collection $models)
    {
        return Transaction::run(function ($batchId) use ($request, $action, $method, $models) {
            //ActionEvent::createForModels($request, $action, $batchId, $models, 'waiting');

            Queue::connection(static::connection($action))->pushOn(
                static::queue($action),
                new CallQueuedAction(
                    $action, $method, $request->resolveFields(), $models, $batchId
                )
            );
        });
    }

when i comment out action event generate , it works superfast.

[tufankilicaslan]

May be its better if we have an option to move action_events table to Nosql database, or need to run this action log generate process in background, for only queued jobs, for a better performance.

[alexbowers]

There might be a way for these to be batched for the action_events table.

[tufankilicaslan]

Yes it should be batched for the action_events table, otherwise we could not say it "Queued Actions". For now, it's like running semi synchronously. Generating "action_events" table records takes more time than the actual " queued actions" :)

[tufankilicaslan]

This is really making big problems, since there is no solution for now, I just disabled action_events by commenting it from core nova code. I am already saving action logs by my self for queued actions.

Not only for queued actions, but also sync actions, it's working extremely slow, because it's trying to add records action_events table as "waiting" then it's updating the record at the same time as "success" or "failed". My cpu fan speeding up when i try to update 5000 records at the same time. After disabling action_logs, it's also working fast for "sync" actions.

I have another issue , i need some help @davidhemphill , i will really appreticate if you can give some information:

For now nova actions divides each request models to chunks. The initial value is : 200, in Action class

    /**
     * The number of models that should be included in each chunk.
     *
     * @var int
     */
    public static $chunkCount = 200;

This is really problem for me, because i am using my custom "scheduling field" on nova actions and organizing jobs before sending to job server. The problem is, my scheduling mechanism is calculating and creating jobs in database , based on the models sent to my nova Action class. So for each requests i have no way to understand if it's part of a previous job or a new job. I did not find any parameter that i could recognize it from my Action class. I want to know and group each action models. Or i just want to disable dividing models into the chunks , instead send all at once. Is there such a way? (I don't want to overwrite $chunkCount because i do not know the max limit)

I opened another issue related about the question: This may have a relation with the issue : #1113

[dkulyk]

This has been fixed and will be included in the next release.