Re: [akka-user][deprecated] Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

Traces`). It's not >> super likely that something will turn up but it seems like a simple enough >> thing to try. >> >> Johannes >> >> On Thursday, November 16, 2017 at 1:28:23 PM UTC+1, Gary Malouf wrote: >> >>> Hi Johannes, >>> >>

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

s you use the `entity[as[String]]` directive? Could you narrow down if there's anything special to those requests? I guess you monitor your GC times? Johannes On Wednesday, November 1, 2017 at 8:56:50 PM UTC+1, Gary Malouf wrote: > > So the only way I was able to successfully identify the

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

ave a deep understanding of streams, but it makes me wonder if the way I have our code consuming the entity is not correct. On Monday, October 30, 2017 at 4:27:13 PM UTC-4, Gary Malouf wrote: > > Hi Roland - thank you for the tip. We shrunk the thread pool size down to > 1, but were dishearten

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

e > > On 23. Oct 2017, at 22:49, Gary Malouf > > wrote: > > Yes, it gets parsed using entity(as[]) with spray-json support. Under a > load test of say 1000 requests/second these latencies are not visible in > the percentiles - they are easy to see because this web server is

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

ment(s"Page-${pr.pageId}", "PageTrace", " kamon") { processPageRequestAndComplete(pr, spr) }, processPageRequestAndComplete(pr, spr) ) } } } On Mon, Oct 23, 2017 at 4:42 PM, Viktor Klang wrote: > And you consume the entityBytes I presume? > > On Mon, Oct 23,

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

what it's worth, this route is a 'POST' call. On Mon, Oct 23, 2017 at 4:30 PM, Viktor Klang wrote: > No, I mean, is it from first-byte-received to last-byte-sent or what? > > On Mon, Oct 23, 2017 at 10:22 PM, Gary Malouf > wrote: > >> We are using percenti

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

of latency are you using? (i.e. how is it derived) > > On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf > wrote: > >> Hi Konrad, >> >> Our real issue is that we can not reproduce the results. The web server >> we are having latency issues with is under peak load of 1

Re: [akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

-- > Cheers, > Konrad 'ktoso <http://kto.so>' Malawski > Akka <http://akka.io/> @ Lightbend <http://lightbend.com/> > > On October 12, 2017 at 15:31:19, Gary Malouf (malou...@gmail.com > ) wrote: > > We have a web service that we just finished mig

Re: [akka-user] Re: Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

Malawski wrote: > > Short lived connections are slightly more costly in Akka-HTTP than in > Spray, due to the streaming infrastructure. > > -- > Cheers, > Konrad 'ktoso <http://kto.so>' Malawski > Akka <http://akka.io/> @ Lightbend <http://lightbend.com/

Re: [akka-user] Re: Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

Thanks > > -- > Konrad Malawski > > On October 13, 2017 at 5:36:06, Gary Malouf (malou...@gmail.com > ) wrote: > >> To be clear, 95th percentile and down are as low as before so wondering >> if this is a new connection closing penalty being paid or if the actor

[akka-user] Re: Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

To be clear, 95th percentile and down are as low as before so wondering if this is a new connection closing penalty being paid or if the actor system needs to be tuned differently now... On Thursday, October 12, 2017 at 4:31:14 PM UTC-4, Gary Malouf wrote: > > We have a web service that w

[akka-user] Spray->Akka-Http Migration - seeing high 99th percentile latencies post-migration

We have a web service that we just finished migrating from spray 1.3 to Akka-Http 10.0.9. While in most cases it is performing well, we are seeing terrible 99th percentile latencies 300-450ms range) starting from a very low request rate (10/second) on an ec2 m3.large. Our service does not do

Re: [akka-user] Akka Streams - output CSV - how to know last line so can avoid appending new line character

Ah - missed that in the API - thanks for the pointer! On Mon, Oct 31, 2016 at 9:47 AM, Viktor Klang wrote: > intersperse? > > On Mon, Oct 31, 2016 at 2:40 PM, Gary Malouf > wrote: > >> I am attempting to use Akka streams to read a large amount of data from a >> data

[akka-user] Akka Streams - output CSV - how to know last line so can avoid appending new line character

I am attempting to use Akka streams to read a large amount of data from a database (in chunks) and output to a CSV on S3. While it may seem trivial, I'm trying to find the best way to identify the final line of the to be created file and avoid putting a new line character at the end of it. Is

Re: [akka-user] Re: Using akka streams to read from streamed source, format and send multi-part file to S3

gt; been made on that recently. > > Jason > > On Tuesday, October 25, 2016 at 6:04:36 PM UTC-7, Gary Malouf wrote: >> >> Just wondering if there are any working examples of creating >> content-on-the-fly and streaming multipart files to s3 with akka streams. >> > --

[akka-user] Using akka streams to read from streamed source, format and send multi-part file to S3

Just wondering if there are any working examples of creating content-on-the-fly and streaming multipart files to s3 with akka streams. -- >> Read the docs: http://akka.io/docs/ >> Check the FAQ: >> http://doc.akka.io/docs/akka/current/additional/faq.html >>

[akka-user] Akka Quartz Scheduler with/as cluster singleton

We use Akka Quartz Scheduler project today to run recurring jobs on each 'node' in our cluster. I now have requirements for jobs that need to be reliably scheduled/executed once per time period across a cluster and I do not believe this

[akka-user] Re: Consistent Hashing for Memcached

Looking at the reference documentation, it appears it may use the same functionality. On Monday, September 29, 2014 2:09:25 PM UTC-4, Gary Malouf wrote: > > I see that Akka has it's own routing implementation based on a consistent > hashing function. Many of the popular Mem

[akka-user] Consistent Hashing for Memcached

I see that Akka has it's own routing implementation based on a consistent hashing function. Many of the popular Memcached clients typically uses a Ketama hash to do their version of this. We have a use case where we want to route messages based on the server in which their co-located data wo

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

Greg - if one uses the current Akka Persistence with eventstore as the backend, is it possible/what are the challenges in getting safe 'process managers' to work as one would expect? I would think you'd want event store feeding a different Akka Persistence processor. On Wed, Aug 20, 2014 at 2:10

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

implicit, as then you are luring > people into the non-scalable world and when they find out then it is too > late. > > > On Tue, Aug 19, 2014 at 3:20 PM, Roland Kuhn wrote: > >> >> 19 aug 2014 kl. 14:57 skrev Gary Malouf : >> >> For CQRS specifically, a lot o

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

For CQRS specifically, a lot of what people call scalability is in it's ability to easily model multiple read views to make queries very fast off the same event data. In the cases where a true global ordering is truly necessary, one often does not need to handle hundreds of thousands of writes per

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

Hi Prakhyat, We are building a CQRS/DDD-oriented configuration system based on akka persistence and are running into the same modeling issues. A few characteristics of our specific case: 1) We do not expect a high volume of commands to be submitted (they are generated via a task-based user inter

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

One of the arguments for CQRS/Event Sourcing combo has been that it allows you to optimize reads and writes independently for high throughput. For many people however (including us) we want the command/query separation + the sequence of events for just the design benefits. Sagas are one of the cr

Re: [akka-user] Improving Akka Persistence wrt CQRS/ES/DDD

I don't see it mentioned on this particular thread, but I feel creating reliable sagas across processors (Aggregates) is a real challenge right now as well. Having a clearly documented way to do this is critical IMO to creating a more complex and reliable CQRS-based apps. On Thursday, August 7

Re: [akka-user] EventSourced/Akka Persistence Transactionally Saving Multiple Events

Thanks Martin, I actually found it after but Akka User List had not approved my post yet so that I could delete it. Appreciate you jumping in, Gary On Friday, April 18, 2014 6:35:35 AM UTC-4, Martin Krasser wrote: > > Hi Gary, > > On 18.04.14 04:05, Gary Malouf wrote: > &

[akka-user] EventSourced/Akka Persistence Transactionally Saving Multiple Events

We have what I believe to be a common use case while using EventSourced actors. When a command enters our system, we produce multiple events as a result. In the event of the system crashing, having some subset of these events saved but others not making it would be a problem possibly. Is th