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

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, >>> >>> Yes;

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

ou get latency spikes as soon as 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 wa

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

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 disheartened to

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

; On 23. Oct 2017, at 22:49, Gary Malouf <malou...@gmail.com > > 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 thi

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 <viktor.kl...@gmail.com> wrote: > And you consume the entityBytes I presum

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

it's worth, this route is a 'POST' call. On Mon, Oct 23, 2017 at 4:30 PM, Viktor Klang <viktor.kl...@gmail.com> 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 <malouf.g...@gmail.com> > wrote: > &

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

wrote: > What definition of latency are you using? (i.e. how is it derived) > > On Mon, Oct 23, 2017 at 10:11 PM, Gary Malouf <malouf.g...@gmail.com> > wrote: > >> Hi Konrad, >> >> Our real issue is that we can not reproduce the results. The web server >> w

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

s, > 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 migrating from spray 1.3 to

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

s > > -- > 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

[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

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 <viktor.kl...@gmail.com> wrote: > intersperse? > > On Mon, Oct 31, 2016 at 2:40 PM, Gary Malouf <malouf.g...@gmail.com> > wrote: > >> I am attempting to use Ak

[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

ot much progress has > 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 st

[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] 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

[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 Memcached clients

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

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

be 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 goo...@rkuhn.info wrote: 19 aug 2014 kl. 14:57 skrev Gary Malouf malouf.g...@gmail.com: For CQRS specifically, a lot of what

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

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

[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

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: We have what I believe