3 ms·

Cool. It's great to see my project on Hacker News! Feel free to ask me any questions here, or using the comment system on the blog post. :-)

by jimpick 10y ago

ShakataGaNai 10y ago
Love the idea. For those who aren't as Lambda savvy you might want to provide some "real world" information on pricing. Ex: This code takes roughly 500ms to run, which means you should expect to pay $0.10 per 96,000 comments on your blog. I know it's stupidly small costs (Lambda is wonderful for that), but some people still don't understand how to translate the pricing structure to "the real world".
- jimpick 10y ago
  Looking at the CloudWatch Logs, each comment seems to take approximately (Billed Duration): 400ms for the initial request, and 800-1000ms for the worker to concatenate the request into the published JSON. It's running in the minimum size of RAM: 128MB
  - prodigal_erik 10y ago
    This is making me wonder whether we should be paying for GC or just having Lambda abandon workers whose heaps are full and spin up more.
    - mrmagooey 10y ago
      I wouldn't have thought the GC would be expensive enough to warrant turning it off, interesting thought though.
    - pmontra 10y ago
      Lambda doesn't destroy the instance at the end of the response. It keeps it running just in case other requests arrive. If that happens you might want GC or a worker eventually runs out of memory. What could happen with Lambda and similar services is that costs will take back under the spotlight "old" languages that run with little memory and little CPU cicles. I'm even thinking about C. I'm not into Go, but that looks like another candidate. Scenarios: those ubiquitous web services running on a single VM because it's more than enough. The customer has to pay for it all the time and could save money if the app can run on Lambda. Enough to pay more in developer time?
      - jimpick 10y ago
        What surprised me with Lambda is that it 'freezes' the VM your code is running in, and 'unfreezes' it when more requests come in. Very clever - they can store a lot of frozen VMs on an SSD. It surprised me when I discovered that a cache I had written in my code was already populated! I think most code running on lambda is not going to be CPU bound. In lambda-comments case it's mostly going to be idling as it waits for TCP/IP traffic to/from Akismet, S3, DynamoDB, Slack notification webhooks, etc.
- cddotdotslash 10y ago
  For anyone looking to calculate Lambda pricing, I made a calculator[1] when developing a previous project. [1] https://s3.amazonaws.com/lambda-tools/pricing-calculator.html https://s3.amazonaws.com/lambda-tools/pricing-calculator.htm...

Cool. It's great to see my project on Hacker News! Feel free to ask me any questions here, or using the comment system on the blog post. :-)

by jimpick 10y ago

Cool. It's great to see my project on Hacker News! Feel free to ask me any questions here, or using the comment system on the blog post. :-)

ShakataGaNai 10y ago

Love the idea. For those who aren't as Lambda savvy you might want to provide some "real world" information on pricing. Ex: This code takes roughly 500ms to run, which means you should expect to pay $0.10 per 96,000 comments on your blog. I know it's stupidly small costs (Lambda is wonderful for that), but some people still don't understand how to translate the pricing structure to "the real world".

jimpick 10y ago
Looking at the CloudWatch Logs, each comment seems to take approximately (Billed Duration): 400ms for the initial request, and 800-1000ms for the worker to concatenate the request into the published JSON. It's running in the minimum size of RAM: 128MB
- prodigal_erik 10y ago
  This is making me wonder whether we should be paying for GC or just having Lambda abandon workers whose heaps are full and spin up more.
  - mrmagooey 10y ago
    I wouldn't have thought the GC would be expensive enough to warrant turning it off, interesting thought though.
  - pmontra 10y ago
    Lambda doesn't destroy the instance at the end of the response. It keeps it running just in case other requests arrive. If that happens you might want GC or a worker eventually runs out of memory. What could happen with Lambda and similar services is that costs will take back under the spotlight "old" languages that run with little memory and little CPU cicles. I'm even thinking about C. I'm not into Go, but that looks like another candidate. Scenarios: those ubiquitous web services running on a single VM because it's more than enough. The customer has to pay for it all the time and could save money if the app can run on Lambda. Enough to pay more in developer time?
    - jimpick 10y ago
      What surprised me with Lambda is that it 'freezes' the VM your code is running in, and 'unfreezes' it when more requests come in. Very clever - they can store a lot of frozen VMs on an SSD. It surprised me when I discovered that a cache I had written in my code was already populated! I think most code running on lambda is not going to be CPU bound. In lambda-comments case it's mostly going to be idling as it waits for TCP/IP traffic to/from Akismet, S3, DynamoDB, Slack notification webhooks, etc.
cddotdotslash 10y ago
For anyone looking to calculate Lambda pricing, I made a calculator[1] when developing a previous project. [1] https://s3.amazonaws.com/lambda-tools/pricing-calculator.html https://s3.amazonaws.com/lambda-tools/pricing-calculator.htm...