[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Security fix that started all this



Hi Jason and Chris;

There is a legitimate tradeoff here that we should probably discuss-- web
servers can be horizontally scaled if necessary while the database server
is going to be harder to scale if the deployment gets really big.  Of
course in these cases, you are likely to have networked filesystems and the
like so the performance gain to having everything local isn't going to be
great by itself but being able to scale gracefully might be a possible
issue.  I am not saying that this quashes the idea but it needs to be
considered.  In fact, I don't think that this is an obstacle at all, just a
caution.

As for big businesses using SQL-Ledger or Leger-SMB, it isn't possible at
the moment for a few reasons that will hopefully be fixed in near-term
releases.  The issues are somewhat technical, but when you have a large
number of transactions (say 60000 invoices) and you don't have projects
and/or departments, you start getting REALLY bad query plans.  As in nested
loop joins with empty tables bad....

Best Wishes,
Chris Travers
Metatron Technology Consulting

Original Message:
-----------------
From: Jason Rodrigues ..hidden..
Date: Fri, 8 Sep 2006 16:53:43 -0400
To: ..hidden..
Subject: Re: [Ledger-smb-devel] Security fix that started all this


On Friday 08 September 2006 16:35, Christopher Murtagh wrote:
>  Yes, but a difference of 50 milliseconds and .5 seconds is negligible
> to a user sitting behind their browser (and I doubt it would be that
> much of a difference). Serving css as a cgi has other advantages,
> including tweaking the css depending on the http_user_agent.  We did
> the same thing for www.mcgill.ca, and it really helped keep display
> logic (tweaking for browser odities, etc) away from the core code and
> allowed us to make the pages look the same in a lot of browsers.

Oh yea, the difference is negligible on a single request, and I'd say that 
communicating w/ the server is the most expensive time-wise part of a css 
request transaction. 

> Yes, again there is more overhead, but are these machines really being
> taxed? I might be completely misjudging how this software is being
> used, but I would imagine that in many cases it is a dedicated box for
> the accounting software, in which case even a PIII could do this
> without blinking. In the cases where the machine is doing other things
> as well, again, it's a matter of scoping out the hardware for the job.
> Are people running their installations on near capacity?

I only bring up this technique because at my 'day job' we used to have css 
served a cgi-registry script, and we had to handle all the little header 
things.  We moved to a 2-server setup, w/ a Apache2 proxy server on the
front 
handling static content where it can (css files, images) and a passing 
dynamic scripts back to the Mod_perl  server.  This frees up mod_perl
servers 
for handling more dynamic content, since they don't have to be idle serving 
static files to slow clients.  it also saved us a bit of bandwidth, our
.cgi 
wasn't handling not-modified responses, and spewed out the whole 3/4k 
stylesheet @ every request.  It added up over the course of a day ...

The real gain, is letting apache handle things like timestamps, 302 not 
modified responses, headers, and what not.

Someone brought up on the list that it is unlikely that *really* large 
organizations are using SQL-ledger for their accounting.  The company I'm 
supporing using this app only has 3-4 users *AT MOST* using the software @ 
the same time.  That's not even req/sec, more like req/min.  Our 1.6ghz p4 
hardly breaks a sweat on this.  And they're doing fairly well revenue wise.

Jason



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job
easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .