Ciao!
I'm on the digest for this list, so pardon my delay in responding to
everyone's comments.
>>>>> "Chip" == Chip Turner <[EMAIL PROTECTED]> writes:
Chip> "Bruce W. Hoylman" <[EMAIL PROTECTED]> writes:
>> Ciao!
>>
>> I would like some input on an intranet web service I am currently
>> in the process of designing, the core of which will be modperl on
>> UN*X.
Chip> Excellent choice. This works quite well. Of course, like
Chip> others on this list, I might be a bit biased.
I'm sort of sneaking this in the back door. Much of the development
surrounding these new objectives is centered in the J2EE architecture.
I'm taking a 'don't say much' approach until it's working and cranking
out the data. Then I'll be able to meet any advances on architecture
choices. It's not that perl/Apache is taboo here, just not looked upon
as an implementation solution of choice. However it won't be the first
time I have faced these pundits.
Chip> How often does the data change? How is it stored on the back
Chip> end? You may not need to cache anything if, say, you have a
Chip> decent SQL database on the backend. Caching never hurts, but
Chip> it isn't always necessary. The Cache::* modules may be of use
Chip> for this, though, should you still need it. You also might
Chip> want to consider not sharing the data in each process; the
Chip> complexity gained vs the memory lost by storing it in each
Chip> process may be a workable tradeoff. I probably would try it
Chip> first with no cache, then a per-process on-demand cache, then
Chip> finally a shared cache, in that order.
I still have to determine the dynamic characteristics of the data in
question. This certainly needs to be taken into account in any cacheing
or local storage of the data. The remote data is Oracle-ized in some
7.x database instances. When I speak of cacheing I'm referring to
taking remote data sources and making the local for some period of time,
after which they must be refreshed and localized again. I don't believe
the service can withstand the cost of remote database access and still
be as streamlined as the requirements specify. However I will be going
through a series of benchmarks to see just which data management
approach is appropriate. I also am keen to the unavailability of these
external, remote data sources. They seem to be 'down' at the most
inopportune moments. In summation, data throughput and availability are
the two most compelling reasons for considering a localized, and I
emphasize READ-ONLY capture of the remote stores (there are two).
Chip> Five hits/second should be absolutely no problem. If you
Chip> expect slow clients, a mod_proxy in front of things
Chip> (http://perl.apache.org/guide) can help.
This is a very interesting section of the guide. I recommend it to
everyone simply for the sake knowing alternative configurations that
include a modperl component.
Chip> There are a lot of options, but really, I would hold off on
Chip> deciding complicated caching schemes until you know what
Chip> throughput you get without them. Even then, I'd avoid
Chip> disk-based cache systems, instead preferring Cache::* if it
Chip> must be shared, or just global variables if it doesn't need to
Chip> be.
This is a good point. I'm working on securing access to the data stores
this week, so I should be able to measure throughput soon. Loading the
in-memory stores direct from the data sources is a good idea, if
necessary. This precludes any local storage of the data which precludes
any refresh to disk logic, although I still will need to flush/fill
memory on a regular basis. Thus I don't want to utilize per-process
data stores, but rather a common shared memory represenetation that all
the modperl processes can draw from
Chip> Can you be more specific about what the data looks like, where
Chip> it resides, and how expensive loading it is? I wouldn't worry
Chip> about optimization yet, unless you know beyond the shadow of a
Chip> doubt speed will be a problem. My hunch is you can do maybe
Chip> 50-100 hits/second on decent Intel hardware via the Frontier
Chip> modules, so I don't think performance will be a problem. This
Chip> is unverified, though; I really need to benchmark it sometime.
Chip> Maybe others have pushed Frontier to its speed limits?
I'll be able to provide some numbers and the actual data representation
later on this week. I agree on performance numbers. I'm getting
awesome throuput now acording to ApacheBench, but that's only with my
skeletal handler. As it I fill it out, I plan on benchmarking each
significant piece of functionality for comparison purposes.
Should be fun.
Chip> Chip
Thanks so much for your insightful comments. I appreciate the time you
took to respond to my queries.
Peace.
