Francesc Romà i Frigolé wrote:
The applications I'm writing are expected to have a relatively small
number of users. From my experience so far the performance is quite good
on a shared hosting as long as I serve the static content from outside
Catalyst. Otherwise performance degrades significantly since each user
has to deal with a few static files that weight a few MB each.
Hmm, well, this strikes me as weird.
I have a 100Mb link (shared with other people) between myself and my
live environment, and I thought I'd do a very quick test.
I tarred up 182Mb of crap.
Static apache: 11.19M/s
Put into a newly generated TestApp in root/static, running with the
development server: 11.18M/s
So I think you're doing something severely non-optimum (or your shared
hosting machines are totally swamped) if you're seeing significant
performance degredation.
Do you see the same issues when testing locally, or just and your shared
host, and what technique are you using to serve these static files?
This approach works for me as long as the static content requires no
authentication or the whole site requires authentication. It just have
to edit a single .htaccess file.
My concern is to keep the setup as simple as possible, and I find this
configuration very advantageous compared to dedicated/virtual hosting
since I don't have to take care of the servers (we are a small team with
more programming than systems administration experience)
YY, that's totally fair - unless you're trying to do reasonable scale
(for example, I can do 3k concurrent sessions on a busy day), then it
_just shouldn't matter_ to you.
Now I'm facing a new situation which is that some parts of the Catalyst
application have to be public. Since it's not a very different situation
than what I had been doing so far I think is legitimate to expect to be
able to solve it with similar tools.
Yep, that's totally fair as long as you're prepared to give up a little
flexibility :)
For completeness sake I'll also say that there is a trivial solution
that avoids this trade off in flexibility: to set up a "guest" account.
But I don't like this solution because it would annoy guest users.
I'd say that the trivial solution is to use
Catalyst::Authentication::Credential::HTTP, and
Catalyst::Authentication::Store::Htpasswd.
As long as you present the same realm name for your HTTP authentication
inside Catalyst as you do outside Catalyst, then users who have logged
into other (non Catalyst powered) parts of your site will never notice.
You then get the flexibility to authenticate on arbitrary paths within
your application, but you're using the same user credentials as other
parts of your site doing apache auth, and everything is just transparent.
Cheers
t0m
_______________________________________________
List: Catalyst@lists.scsys.co.uk
Listinfo: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst
Searchable archive: http://www.mail-archive.com/catalyst@lists.scsys.co.uk/
Dev site: http://dev.catalyst.perl.org/
