[tor-dev] onionoo resource requirements

[Karsten Loesing]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 27/04/15 23:39, l.m wrote:
> Hi Karsten,
> 
>> Not sure what frameworks you have in mind.  But I'm happy to hear
>> more about frameworks that would make Onionoo easier to extend
>> and not perform worse (or even better) than now.  If you have
>> something in mind, please say so.
> 
> Thanks for the clarification. I'm not against the  choice of Java,
> nor claiming better choices. I have fond memories of  Java. In
> particular I've been working a lot with Django recently. I didn't
> want to  redo works that may have already been performed. I was
> thinking of some recreational uses of a server. I started looking
> at the onionoo documentation and my curiosity was piqued. Precisely
> because the first thing I thought of was reusing a cloned server
> for, well, a onionoo-clone.
> 
> The JSON formatted files could be used as fixtures  for setup. The
> two apps could be run separately as you've already mentioned.
> 
> The other development specifics are: 
> nginx-gunicorn(greenlets/aiohttp) postgresql-pgbouncer
> 
> Is it an experiment worth pursuing? Your thoughts are appreciated. 
> Thanks in advance.

Regarding Python, we already tried rewriting Onionoo in Python a few
years back and failed.  It's a larger project than it seems, and the
possible benefits probably won't justify that.  (Just think of the
many new features we could write while rewriting existing ones.)

Using Java for the back-end and Python for the front-end is a bit
ugly, but could work if there's a true benefit in that.  Though we
might be able to re-use the concepts from the Python experiment and
incorporate them in the current Java implementation.  I very much
doubt that performance advantages would be attributed to Python vs.
Java, but here I am starting to argue about programming languages,
which I shouldn't.

I think the best way to improve things is to look into switching to a
SQL database.  I already started experimenting with that in the past
two weeks and just wrote down my findings here:

https://trac.torproject.org/projects/tor/ticket/15844

If you're interested in some database performance hacking, you'll love
this ticket!  Much appreciated!

All the best,
Karsten

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJVP37JAAoJEJD5dJfVqbCrE9oH/207mKD4Hhc1dcBpWvNP+oYR
p4u1Xgx4j6804Hhl26kiPXm4K43FDMG0vZ/YmIxJKGggPvdP8ZesiunH2bGtYISr
FeHu2+72H4d8p1WadFN5UBWENrYX49qCcuUBSzquRtGK1pnlbTlbOiLGc2iSdSZT
cLoTZcAtyIEms8+lAswNmrZR6E3FMQqvmhtGSWeL7KihoNcKqsH0y5Dnogkj/Vyb
Lez5eCDfJy4sV2eJtfPqySzMt67wbBCJ4PdpXsXX3iTx1H0clUwQbzKwiEv9PpFT
IQpyWIKA9ErW0hMUiz192sB6dGYRSySfZHG/z9Jrs9M6t6UmhJbA1jHvvvabs/o=
=IeUy
-----END PGP SIGNATURE-----