[erlang-questions] count events within last XX minutes

Gleb Peregud gleber.p@REDACTED
Sun Aug 26 10:30:51 CEST 2012


Lately when working on project with up to a million concurrent clients
connected I had to replace few instances of central servers with a public
ets'es to avoid bottlenecks under heavy concurrent access. So choice of
data storage may depend on what are access patterns of your data - i.e. how
concurrent reads and writes are.

On Aug 26, 2012 10:22 AM, "Max Bourinov" <bourinov@REDACTED> wrote:
>
> >If you put stats into public ets, than collector will not be
> >overloaded with requests.
>
> This is interesting. I also have thoughts about avoid DOS. But I don't
understand how ETS will help here.
>
> Here what I have. I have only one process that process clients requests.
It really doesn't make sense to have more processes because the process
does nothing but returns some pre-calculated value. If I store data in ETS
my process will have to do additional work - extracting data from ETS.
>
> Or maybe I am missing something? Please give the right direction here. Or
maybe in my case it doesn't matter because my case is trivial?
>
> Best regards,
> Max
>
>
>
> On Sun, Aug 26, 2012 at 12:04 PM, Max Lapshin <max.lapshin@REDACTED>
wrote:
>>
>> On Sun, Aug 26, 2012 at 12:02 PM, Michael Truog <mjtruog@REDACTED>
wrote:
>> > There often is a habit with quick projects to throw data in ets, since
it is
>> > easy to access the data as global data.  This helps people coming from
an
>> > imperative programming background.  I don't see a good reason in the
email
>> > thread that shows that ets is the best solution,
>>
>>
>> But there is a good reason. It is performance. For example, in
>> erlyvideo all major statistics data are
>> collected not via gen_server:cal: you cannot ask process to tell its
>> statistics, because
>> it is very easy to DOS your server with such replies.
>>
>> If you put stats into public ets, than collector will not be
>> overloaded with requests.
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120826/7f372732/attachment.htm>


More information about the erlang-questions mailing list