Concurrency in Ruby on Rails 4

[David Williams]

How would you approach developing an app that requires expedient
transactions? Would the EventMachine gem did the trick in terms of
persistence and reliability?

--
Posted via http://www.ruby-forum.com/.

[Hassan Schroeder]

On Wed, Nov 19, 2014 at 11:35 AM, David Williams <li...@ruby-forum.com> wrote:
> How would you approach developing an app that requires expedient
> transactions?

What exactly do you mean by "expedient transactions" in the context
of a web application?

--
Hassan Schroeder ------------------------ hassan.s...@gmail.com
http://about.me/hassanschroeder
twitter: @hassan

[David Williams]

Hassan Schroeder wrote in post #1162850:

Essentially the fasted method for transferring data between
client/server.

[Scott Ribe]

On Nov 20, 2014, at 12:42 PM, David Williams <li...@ruby-forum.com> wrote:
>
> Essentially the fasted method for transferring data between
> client/server.

That's literally a meaningless question. You're really going to have to clarify your question before you can expect any answer.

- Latency of individual requests and total number of requests throughput are two different issues.

- Getting data out of a database, getting static assets from cache or disk, building responses to requests (whether HTML or JSON or whatever, sending the responses to the browser, and rendering the result in the browser, are all separate issues.

So: lots of clients? busy clients? large requests? large database backing the site? large or complex assets? complex processing of requests? complex browser rendering?

--
Scott Ribe
scott...@elevated-dev.com
http://www.elevated-dev.com/
(303) 722-0567 voice

[David Williams]

Scott Ribe wrote in post #1162964:

> On Nov 20, 2014, at 12:42 PM, David Williams <li...@ruby-forum.com>
> wrote:
>>
>> Essentially the fasted method for transferring data between
>> client/server.
>
> That's literally a meaningless question. You're really going to have to
> clarify your question before you can expect any answer.
>
> - Latency of individual requests and total number of requests throughput
> are two different issues.
>
> - Getting data out of a database, getting static assets from cache or
> disk, building responses to requests (whether HTML or JSON or whatever,
> sending the responses to the browser, and rendering the result in the
> browser, are all separate issues.
>
> So: lots of clients? busy clients? large requests? large database
> backing the site? large or complex assets? complex processing of
> requests? complex browser rendering?

You're right, it depends on the size of the service and how much data is
actually being sent during each request.