On Dec 19, 2013, at 12:44 , Torsten Valentin <[email protected]> wrote:
> thank you very much for your opinion. I appreciate that very much. It
> took me some time to write this reply since I wanted to examine some
> of your advises first.
>
>
>> Overall, you are trying to make the HTTP server your SDK client. I
>> would recommend against that.
>
> Why do you not recommend that? And what do your recommend instead when
> encryption and secure authentication are the top priorities?
Torsten,
Please bear in mind that I am not a Couchbase employee and I sell my
technical advice services. Many of your questions require a deeper analysis
than a public forum would allow.
That said, Apache, like the HTTP protocol itself, is largely stateless.
This has many performance implications. Secondly, your faith in Apache's
security may be misplaced. It is a very large and complex piece of software. It
is a workhorse of eCommerce but it is not intrinsically secure. There are
simpler HTTP proxies that handle the SSL unwrapping and scale to the moon. As
you claim security is your number one priority, you may wish to examine them.
Your database tier is all about state. It maintains your state. The
Couchbase client is part of your database tier/business logic tier. Because of
all of the state it must maintain, it needs a continuous process. Apache and
its various modules cannot provide that context. Couchbase gains its
scalability from this extra state. To meet your architecture, the CB clients
support a connection document cache that reduces the time needed to load a
client. But it will never be as good as loading a persistent client -- there is
just too much connection flap.
I'm going to defer answering the rest of your questions until you
understand this issue of a stateless server versus a state-full database tier.
This is the crux issue causing all of your performance problems.
Anon,
Andrew
>> Your SDK Client and cluster together form your database tier.
>
> OK. Maybe it's clear for you but I still don't see the drawback. Since
> the first priority is to encrypt the transport layer and have
> certificate based authentication, my approach appears somewhat "obvious"
> to me. But maybe I'm just routine-blinded. How else would you solve
> this? Ah, sorry, no top priority is stable code, then secure transport
> layer, then certificate based authentication, then performance, then
> scalability, then replication.
>
>
>> First, you should allow your connections to persist between
>> queries.
>
> Here your answer has probably already helped me a lot since I assumed
> that modperl would already make sure db connctions would be persistent.
>
>
>> Second, languages such as Perl and Python have hardened standard
>> libraries for SSL and HTTP. What are you getting putting Apache in
>> the way of your database transaction?
>
> If that's not meant to be a rhetorical question, here's the answer:
> Because there's nothing that has been audited as much as Apache. Apache
> itself is bullet proof in terms of security as long as you don't weaken
> it by implementing crappy mods. Security is top priority and so even CB
> will not be accessible from anything else but our own scripts.
>
>
>> Third, if you must use an HTTP security proxy, you should consider
>> Nginx or one of the load balancer daemons.
>
> Agreed as long as security is not the top priority. I do understand your
> point and I'm not saying other products are insecure or bad. But in
> terms of how much the code was audited to get rid of all the wholes and
> bugs there's nothing like Apache.
>
>
>> Apache isn't really designed for the low latency, high connection
>> rate application you are asking of it.
>
> Everything's a trade off. Apaches performance does well enough for me
> with my "hello world" example. I'm sure you can optimize that using
> different servers and different techniques. But we have other priorities.
>
>
>> Apache doesn't maintain connection state. Hence, you will be
>> reestablishing the connection to the cluster per transaction.
>
> Thanks. I'm going to examine this further, however, I'd really like to
> know what you think would be a good design with the given priorities.
>
> Thanks a lot!
>
> T.
Anon,
Andrew
____________________________________
Andrew W. Donoho
Donoho Design Group, L.L.C.
[email protected], +1 (512) 666-7596, twitter.com/adonoho
Download Retweever here: <http://Retweever.com>
No risk, no art.
No art, no reward.
-- Seth Godin
--
You received this message because you are subscribed to the Google Groups
"Couchbase" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
