Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

question: AWS Lambda get pretty slow when using decorators #1587

Closed
sebastianroming opened this issue Mar 17, 2022 · 6 comments
Closed

question: AWS Lambda get pretty slow when using decorators #1587

sebastianroming opened this issue Mar 17, 2022 · 6 comments
Labels
type: question Questions about the usage of the library.

Comments

@sebastianroming
Copy link

I'm using class-validator in my newly created AWS lambda.
When using the property decorators provided, like @IsString(), the lambda gets painfully slow when invoking locally (~150ms without decorators, ~4000ms with decorators).

I'm not even validating the incoming object, just the fact the decorators are present slow down the lambda (as you may see):

lambda handler (handler.ts)

export const serviceRequestsHandler = async (event: APIGatewayProxyEvent & { body: RequestBody, queryStringParameters: RequestQueryString }): Promise<APIGatewayProxyResult> => {

  const parsedBody: RequestBody                   = new RequestBody(event.body);

  return new ResponseFactory().statusCode(204)
                              .body(null)
							  .factory();
};

RequestUser.ts

import { IsString } from 'class-validator';

export class RequestBody {

  @IsString()
  contact_person: string;

  @IsString()
  machine_identifier_customer: string;

  @IsString()
  message: string;

  constructor(request_body: RequestBody) {
    this.contact_person              = request_body.contact_person;
    this.machine_identifier_customer = request_body.machine_identifier_customer;
    this.message                     = request_body.message;
  }

}

As you can see, no hard work is done here what could cause an increase of ~4000ms, and no validation of the event.body object itself.
If I get rid of the decorators, runtime decreases, as mentioned, to about ~150ms.

Anyone has a guess what could cause this?

Thanks!

@sebastianroming sebastianroming added the type: question Questions about the usage of the library. label Mar 17, 2022
@NoNameProvided
Copy link
Member

I don't provide support about how to use AWS.

If the issue still persists, you may open a new Q&A in the discussions tab and maybe someone from the community may be able to help.

@ajwootto
Copy link

@NoNameProvided we're actually running into this as well with Cloudflare Workers, and I think it's a good problem to think about that is more specific to the way the library works inside of "serverless functions" (not specifically AWS).

Basically I believe this library is performing a lot of work on startup to build the schemas for validation based on the class decorators. Normally that's fine in a long-running server application, but it seriously harms performance in a serverless function that starts up once in an isolated memory space, initializes all the schema stuff, does a little bit of work and then shuts down.

The only way around this that I could see would be to provide a way to take the class definitions and "precompute" the schemas as part of the build process (webpack etc.). If the library had some generalized support for that kind of thing it would be pretty useful I think.

@NoNameProvided
Copy link
Member

Hi @ajwootto!

Thanks for the reply. Since this is nonactionable feedback ("it slow but no metrics") I cannot act on it. As a result please open a feature idea discussion where you

  • explain what is wrong
  • provide your use case (how and many class you decorate, what kind of data you validate)
  • provide some statistics on what is slow and how many items you use
  • write your idea about how this can be solved

After this, the community can iterate on the idea, discuss the next steps and when we know what we should do we can open a feature or fix the issue.

Basically I believe this library is performing a lot of work on startup to build the schemas for validation based on the class decorators.

I suspect something else is at play here, it should be not noticeable to build the metadata even if you have significant amount of decorated classes.

The only way around this that I could see would be to provide a way to take the class definitions and "precompute" the schemas as part of the build process (webpack etc.).

This is actually planned. class-validator should be able to emit its metadata in a serializable way. My initial idea was that this can be used for sharing the same validation logic between servers and or frontend, but it fits well your use case as well. However, it's important to note that this won't be implemented quickly, as first I need to get this repo in order. (See #1775 for details.)

@Shereef
Copy link

Shereef commented Nov 22, 2022

@NoNameProvided I am willing to have a crack at implementing this next week if you give me some advice on how you think it can be done

We are also using aws lambda and performance is paramount for us.

I agree #1775 is much more important so please focus on that and release what you have today ASAP so that snyk and re-evaluate and remove the vulnerability warning

Please and thanks!

@NoNameProvided
Copy link
Member

First, we need to understand what is slow in class-validator when running in Lambda, and why it is slow.

If I would take a look at it, I would start by running my test cases with the NodeJS debugger attached and analyze the results of a few runs with profiling. The resulting flame graph will tell you when the most time is spent.

@github-actions
Copy link

github-actions bot commented Jan 2, 2023

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 2, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
type: question Questions about the usage of the library.
Development

No branches or pull requests

4 participants