Re: Direct Action vs. Component Action...
Re: Direct Action vs. Component Action...
- Subject: Re: Direct Action vs. Component Action...
- From: Anjo Krank <email@hidden>
- Date: Fri, 28 Jul 2006 10:23:40 +0200
So, it might be faster for you, if you don't have to continously
consult the database for each and every page to get always the same
content (e.g. navigation entries or advertisement).
Depends. You might just cache GIDs and then create faults. And also
register to-many faults for certain source GIDs. Then EOF doesn't go
to the DB, only when the data gets stale. In particular for users and
navigation entries this works pretty well.
Cheers, Anjo
Am 28.07.2006 um 09:55 schrieb Guido Neitzer:
On 28.07.2006, at 4:17 Uhr, Deepak Nulu wrote:
Thanks for this very illuminating data point.
There's another point here:
Our traffic has lowered by about 70 percent after the switch. Bad
designed search engines may blow the session creation to limits you
haven't seen before ... we have seen Google pushing the session
generation of our site by about 4 new sessions per second ... :-(
But okay, it showed that if nothing else happens in a session, a
dual G4 867MHz with 2GB RAM can handle this to a at least about 300
sessions on each of the four instances before significantly
suffering ... ;-)
Google can be controlled with robots.txt but e.g. the Microsoft
search engine didn't give a cent for the file and crawled our site
again and again - hopeless, because it always came to front page
(session timeout) and wasn't intelligent enough to see that. We had
to ban several IPs from the Microsoft range to get rid of that.
So the numbers may give some false information because the
frontpage was shown over and over again to search engines and this
was fast - faster than e.g. the searches inside the application.
Actually the numbers were that the session based application was on
average three times faster, but after we got rid of the "unwanted
pageviews" it was only 30%. And that was because of our application
layout where we are building the complete navigation from database
entries ("Pages") and cached them in the session which we can't do
now.
So, it might be faster for you, if you don't have to continously
consult the database for each and every page to get always the same
content (e.g. navigation entries or advertisement).
To track a login, a cookie might a an idea. But not everyone allows
cookies ... So, I'd do as much of a public site as possible in DAs
and only the portion the MUST be evaluated with a login either with
component actions and a session or a cookie. If you start storing
more and more information in the session (user, shopping cart and
so on it's just more convenient then using a cookie information to
store/retrieve this information in a database file - like Ruby does
automatically).
cug
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40logicunited.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden