First, code has been committed into addons/* for 1.3 and into mainline for
1.4. Early adopters should talk with me about how to install on 1.3.
On Fri, Aug 31, 2012 at 9:05 AM, Ed W <[email protected]> wrote:
>
> Hi folks, I have spoken to Chris about this a little offlist, so I just
> want to stress that this is meant to be a positive sounding question!
>
> What kind of speeds are you currently seeing page render requests with
> Plack/Starlet? I just want to jump in with an abstract benchmark, but
> we should be aiming to get all screens which do trivial backend
> processing to be performing in the sub 100ms response time frame. In
> fact for trivial screens on a sensible sized box we really should be
> seeing sub 50ms response times.
>
I have not run through profilers specifically. I haven't quite figured how
to do this yet. However, on my system, basically the way it works is that
we preload all the expensive modules and then, fork, run, die. This
prevents legacy SQL-Ledger code from corrupting the Perl interpreter on
multiple runs, which actually happens and it means that SQL-Ledger code is
not cached. We could probably cache more LedgerSMB code and speed things
up a bit but that would be marginal gains so far and not 100% sure how
helpful it will be.
Typically what I have seen on my development system is a drop from approx 3
sec-5 sec response time to most requests to well under a second. I have
been unable to hook profilers in and don't know how much of the delay now
is due to browser processing, but the speedup is significant. Profiling on
the scripts run as full CGI show over 60% of the time being thing like
initializing the localization classes. This is all moved to service
startup in this model.
I am getting errors on Starman (not Starlet) but not sure if it is my
environment or the .psgi or the code or what.
>
> As a data point I am currently working on a mojolicious (perl) web
> configuration interface for an embedded (ish) box which runs on a 500Mhz
> Geode (Alix). This generates real web pages in around 80-120ms despite
> the rather wimpy processor (those are "to the browser" speeds, not just
> rendering speed). I haven't benchmarked on a proper machine, but
> roughly this machine benchmarks at around 10% of my Q6600 2.4Ghz machine
> (single threaded).
>
> I'm not sure if you have looked at Mojolicious, but it's now a very
> mature and flexible toolkit for building all kinds of web services. The
> code is fantastically clear and concise and well worth a look for
> inspiration. Basically all of its features are simple packages and have
> been implemented in a remarkable simple fashion. It does seem to steer
> a decent line between "opinionated" and "flexible"
>
> I would recommend it as an interesting option for LSMB, not least
> because it's more of a "VC" than an "MVC" system, you are left to
> implement the "M" yourself. It also provides a lot of the plumbing for
> templating systems, ajax, pjax, webservices, etc. It's such an easy
> architecture to work with it's likely a potential "drop in" change...
>
>
I think we should be further discuss this perhaps on a separate thread (the
Mojolicious bit).
Best Wishes,
Chris Travers
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Ledger-smb-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
