Some thoughts I've had last night while handling a beer:
A web UI for Cassandra, will be sometimes querying remote APIs (JMX,
Thrift), for every node in the cluster.
So, about the non-blocking/blocking issue that Brandon pointed out:
---------
In a totally synchronous/blocking approach, I expect this scenario:
request_some_value_for_every_node:
for every_node
request_value_from_api_and_wait (this is a request itself)
add_value_to_some_list
return list_of_values
------
In a more async/non-blocking approach, this other case:
request_some_value_for_every_node(callback: when_its_done):
for every_node
request_value_from_api_and_wait
add_value_to_some_list
when_its_done:
return list_of_values
-----------
I wast just wondering if we should leave async servers/frameworks out
of the question, or, in the opposite, think about how we can get a
benefit out of them, having in mind that the UI will be querying API
methods for nodes in an entire cluster sometimes.
Here's some info about various servers including Tornado:
http://nichol.as/asynchronous-servers-in-python
On Mon, Apr 12, 2010 at 9:05 AM, Pablo Cuadrado <pablocuadr...@gmail.com> wrote:
> So far, I think I'm going for Pylons, the discussion gave this "pseudo-votes":
>
> Pylons +3
> Tornado +1
> Django +1
> Undetermined +2
>
> Any further comments on this issue will be appreciated!
>
> Thanks!
>
>
> On Sun, Apr 11, 2010 at 4:58 AM, Eric Florenzano <flo...@gmail.com> wrote:
>> Bottom line with this kind of a project is to go with what you're most
>> familiar with. If you're equally unfamiliar with all frameworks, then the
>> quality of documentation becomes more important.
>>
>> Personally, I'd take a hard look at Werkzeug--it's a library, not a
>> framework. Which means you get to pick and choose what bits you want in a
>> sort of a-la-carte way. In the end, similarly to Pylons or Django, you get
>> a WSGI app that can be served out of the many different WSGI-aware web
>> servers like Apache's mod_wsgi, gunicorn, cherrypy, or even the builtin
>> wsgiref from the standard library.
>>
>> Anyway, I'm not sure if that helps or makes things more confusing :)
>>
>> Thanks,
>> Eric Florenzano
>>
>> On Fri, Apr 9, 2010 at 10:23 AM, Pablo Cuadrado
>> <pablocuadr...@gmail.com>wrote:
>>
>>> It is indeed a web framework, and made for sys admins to interact with
>>> Cassandra, not for hosting millions of users concurrently.
>>>
>>> And you're right: those are helloworld benchmarks.
>>>
>>> I was concerned a few days ago about the sync/async issue, browsing
>>> over examples on Telephus, Twissandra, Lazyboy, Pycassa... then I
>>> thought that Lazyboy is largely being used in production AFAIK, so
>>> I've just kept it in my mind.
>>>
>>> However, the communication layer for the web UI, should (and hopefully
>>> it will) be independent, in case we want to make this changes in the
>>> future.
>>>
>>> On Fri, Apr 9, 2010 at 2:10 PM, Joseph Bowman <bowman.jos...@gmail.com>
>>> wrote:
>>> > I don't really consider any hello world benchmarks valid, you'd want to
>>> > investigate what your implementation would entail in different frameworks
>>> > and do mini-benchmarks to validate which is faster. But, if it's just a
>>> web
>>> > framework, as Brandon said, I doubt performance will matter to any great
>>> > degree. You'd be more concerned about Cassandra's performance, which is
>>> > pretty darn good.
>>> >
>>> > On Fri, Apr 9, 2010 at 1:07 PM, Brandon Williams <dri...@gmail.com>
>>> wrote:
>>> >
>>> >> On Fri, Apr 9, 2010 at 12:04 PM, Pablo Cuadrado <
>>> pablocuadr...@gmail.com
>>> >> >wrote:
>>> >>
>>> >> > Yes, I'm planning on Lazyboy.
>>> >> >
>>> >> > The Performance part on the Tornado wiki is quite impressive. Do you
>>> >> > think it's accurate?
>>> >> >
>>> >> > http://www.tornadoweb.org/documentation#performance
>>> >>
>>> >>
>>> >> Using Lazyboy, you'd be mixing blocking sockets with a nonblocking event
>>> >> loop, so performance is likely less than optimal. That said, I doubt
>>> >> performance is a concern with a web UI.
>>> >>
>>> >> -Brandon
>>> >>
>>> >
>>>
>>
>
